Re: Can it really be this quiet?
On Mon, Jan 03, 2022 at 02:46:59PM -0500, Allen McKinley Kitchen (gmail) wrote: > Or has NANOG also succumbed to a signed-integer date problem? > > Waiting to see what I get back.. Don't jinx it... > ..Allen -- Brian Reichert BSD admin/developer at large
Re: replaying captured traffic
On Tue, Nov 26, 2019 at 01:07:56PM -0500, harbor235 wrote: > I am hoping someone can provide wisdom regarding the dos and don'ts > replaying captured traffic? Googling 'pcap replay' yields many hits. > Is open source tools sufficient? > > Can PCAPs be replayed? This is an easy answer: https://tcpreplay.appneta.com/ https://github.com/appneta/tcpreplay etc... I've tried none of them. > How is this accomplished? partial rewriting IP headers > > Recommended tools? > > Mike -- Brian Reichert BSD admin/developer at large
Re: Art and Tech is madness
On Thu, Sep 05, 2019 at 11:04:30PM -0500, Chris Boyd wrote: > There???s also this gem from 2005 or 2007 days. I???ve heard Cisco staff was > involved in its creation. > > http://www.mattzrelak.com/mp3/t1down.htm If this is keeping on topic: https://www.youtube.com/watch?v=CyvQ5Pu_k1o > > ???Chris -- Brian Reichert BSD admin/developer at large
Re: Wi-Fi Analyzer
On Fri, Dec 29, 2017 at 09:17:26AM -0600, Bryan Holloway wrote: > Curious if the community has any recommendations and/or positive > experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer. > > Software/laptop-based solutions can be unwieldy in certain environments. > However, given rave reviews, I'm open to the idea as long as it's > Mac-compatible. > > Should be able to show detailed spectra, help locate sources of > interference, have mapping capabilities, etc. Depending on what problem you're trying to solve, on my Android phone I use a free app called 'Wifi Analyzer': http://wifianalyzer.mobi Shows me what station IDs are on what channels, handles 2.4g and 5G connections, etc. Doesn't provide mapping, just shows "from where I am right know, what channels have which stations as what strengths?" For a house, it's easy to walk around, to passively get a feel for Wifi placement/config. > Thanks! -- Brian Reichert BSD admin/developer at large
T-Mobile's Binge On violates net neutrality, says Stanford report
Presumably, this is getting some eyes: http://www.tmonews.com/2016/01/t-mobiles-binge-on-violates-net-neutrality-says-stanford-report/ T-Mobile's Binge On violates net neutrality, says Stanford report In a new report published today - and filed to the FCC, as well - van Schewick says that Binge on "violates key net neutrality principles" and "is likely to violate the FCC's general conduct rule." -- Brian Reichert BSD admin/developer at large
Re: Whois.net down?
On Thu, Sep 03, 2015 at 07:57:55PM +, Marcin Cieslak wrote: > whois.net is some site operated by NTT/Verio, > this domain tech contact seems to be: > > Tech Name: Verio Hostmaster > Tech Organization: > Tech Street: 8005 S. Chester Street Suite 200 > Tech City: Englewood > Tech State/Province: CO > Tech Postal Code: 80112 > Tech Country: US > Tech Phone: +1.2142908620 > Tech Phone Ext: > Tech Fax: +1.2147451877 > Tech Fax Ext: > Tech Email: hostmas...@verio.net > > although you might have better chance via Twitter > https://twitter.com/WhoisNet :( Thanks for the suggestion. :) > ~Marcin -- Brian Reichert BSD admin/developer at large
Re: Whois.net down?
On Thu, Sep 03, 2015 at 09:59:02PM +0700, David S. wrote: > Hi Brian, > > I'm able to access https://whois.net, have you check the nameserver of > numachi.com? > Is the other domain use same authoritative DNS? I can access the web page. When I use the page for certain domains, sometimes, I successfully get results. Other domains, such as NUMACHI.COM, I get the error I reported. CLI-based versions of whois work just fine for all domains I'm concerned about; it's that web-baed version that is selectively failing. > Best regards, > David S. -- Brian Reichert BSD admin/developer at large
Whois.net down?
I'm trying to use https://www.whois.net/ to resolve info about several domains, including my own (NUMACHI.COM). For several domains (but not all, I get 'Error extracting data. No data available'. There's a 'please read' tag, but no text associated with it. Anyone know if they're having issues there? -- Brian Reichert BSD admin/developer at large
Re: huawei (oscilloscopes and frequency analysis)
On Tue, Jun 18, 2013 at 02:31:37PM -0600, Phil Fagan wrote: > now THAT would be a cool project! (I missed the beginnig of this thread; sorry if this is a repeat.) There was the fellow demonstrating a spoofed 2G GSM tower at DefCon recently: http://www.forbes.com/sites/firewall/2010/07/31/despite-fcc-scare-tactics-researcher-demos-att-eavesdropping/ And the YouTube video was pretty cool to watch, for technical depth. https://www.youtube.com/watch?v=rXVHPNhsOzo Part of his talk described how he could (up a point) block 3G, to cause phones to fail over to 2G, where he could get them. 4G is a whole different thing, but the talk was educational, nonetheless... > -- > Phil Fagan > Denver, CO > 970-480-7618 -- Brian Reichert BSD admin/developer at large
Re: Should host/domain names travel over the internet with a trailing dot?
On Tue, Feb 26, 2013 at 09:07:24AM +1100, Mark Andrews wrote: > > In message <15455394.7034.1361803759023.javamail.r...@benjamin.baylink.com>, > Ja > y Ashworth writes: > > More formally: "is a host/domain name with a trailing dot *actually a > > legal host name? > > No. See RFC 952 In the case of URIs, RFC 2396 (circa 1998) seems to allow for it, if I read the ABNF for 'hostname' right in section 3.2.2. But that's the only place I see it. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Mon, Feb 25, 2013 at 10:10:55AM -0800, Doug Barton wrote: > Brian, > > This may be a silly question, but what's your goal here? Your OP was > about terminology, but the thread has gone down several different > off-topic ratholes. That was indeed by original goal, and there have been a couple of useful suggestions, and I thank this forum for all of the suggestions and feedback. I later mentioned why I was pursuing the terminology (use case surrounding entries in a SAN), and there's some effort to consider whether or not my issue is really a non-issue. Which it might be. > Doug -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote: > If I understood Brian correctly, his problem is that people/programs > are trying to retrieve things from, eg: > > https://my.host.name./this/is/a/path > > and the SSL library fails the certificate match if the cert doesn't contain > the absolute domain name as an altName -- because *the browser* (or whatever) > does not normalize before calling the library. I'd argue that if you have an absolute domain name, then that _is_ the 'normalized' form of the domain name; it's an unambigious representation of the domain name. (Here, I'm treating the string as a serialized data structure.) Choosing to remove the notion of "this is rooted", and then asking any (all?) other layers to handle the introduced ambiguity sounds like setting yourself up for the issues that RFC 1535 was drawing attention to. > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Brian Reichert BSD admin/developer at large
Re: Should host/domain names travel over the internet with a trailing dot?
On Mon, Feb 25, 2013 at 11:26:47AM -0500, Jay Ashworth wrote: > > The upshot (assuming I'm not totally off base here), is that other > > than getaddrinfo(), nothing is acting on the semantics of the > > supplied hostname (or IP address). They are 'just strings', and > > are (essentially) compared as such. > > Right. And I'm asserting that that's wrong: the client side libraries > Really Ought To normalize that name before trying to compare it against > the retrieved certificate to see if it matches, which would relieve you > of having to have the altName with the trailing dot in such a cert. I know for internal testing, I've had to introduce unqualified hostnames in the CSR as well (e.g. 'testhost', instead of 'testhost.example.com'), to handle the case of the client not using domain names at all (when framing queries). This illustrates that there's not even an effort to synthesize a FQDN. Who should implement the normalization logic? Not the SSL library, certainly. That sounds like the bailiwick of the resolver library... > The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing > some work this morning, but that's up in a tab for coffee breaks; I'll > try to figure out what I think Dierks and Allen thought about this topic, > if anything, during the day. I look forward to the fruits of your research. :) > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Brian Reichert BSD admin/developer at large
Re: Should host/domain names travel over the internet with a trailing dot?
On Mon, Feb 25, 2013 at 09:49:19AM -0500, Jay Ashworth wrote: > - Original Message - > > From: "Brian Reichert" > > > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: > [I believe this is Brian, then Mark: ] > > > > When I did my initial development with OpenSSL, I observed: > > > > > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > > > client stack would fail the verification if a rooted domain name > > > > was used to connect to the SSL server. > > > > > > Well you have a broken SSL client app. If it is accepting non legal > > > hostnames it should be normalising them before passing them to the > > > ssl layer. > > > > From what little research I've done (only OpenSSL), the SSL client > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > haven't found an implementation of getaddrinfo(3) that rejects > > rooted domain names as non-legal. > > Yes, but that's not the question, Brian, assuming I understand the problem > as well as I think I do. The question is not how the client does the > name resolution on the client machine -- it's what it does with the domain > name it's looking up before doing the SSL interaction with the server side, > a process with which I'm not familiar enough to know if the client actually > send the host/domain name to the server end. Assuming it does -- and I > am -- the question is: should it take the dot off. My understanding is this: Unless you're doing client certificate verification (wherein the server is making decisions about which clients attempting a connection), all validation/verification is done by the client. The SSL client retrieves the server's certificate, and the set of values in the Subject and the Subject Alternative Name is compared against the hostname/IP address used to initiate the process. This comparison is (to my understanding) straight-forward (modulo UTF8 encodings, etc.). The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such. > Cheers, > -- jr 'yeah, I know, it's Monday' a > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: > > When I did my initial development with OpenSSL, I observed: > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > client stack would fail the verification if a rooted domain name > > was used to connect to the SSL server. > > Well you have a broken SSL client app. If it is accepting non legal > hostnames it should be normalising them before passing them to the ssl > layer. >From what little research I've done (only OpenSSL), the SSL client is relying on getaddrinfo(3) to do name resolution. In turn, I haven't found an implementation of getaddrinfo(3) that rejects rooted domain names as non-legal. Looking for couter-examples... > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Fri, Feb 22, 2013 at 03:30:57PM -0800, Geoffrey Keating wrote: > This is clarified in RFC 3280: > >When the subjectAltName extension contains a domain name system >label, the domain name MUST be stored in the dNSName (an IA5String). >The name MUST be in the "preferred name syntax," as specified by RFC >1034 [RFC 1034]. I agree on what that spec says. My concern that that a rooted domain name is (will be?) valid in practice, and is supported by client software seemingly everywhere. The spec for a URL also calls out what constitutes a hostname, and I've yet to see a HTTP client that trips over a rooted domain name. (Yes, I'm aware an alternate bit of terminology has been proposed, but I'm trying to be consistent for the duration of this thread.) Still, I'm not arguing about what should be allowed; I'm trying to come up with the words to explain to end-users. -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Fri, Feb 22, 2013 at 05:46:27PM -0500, Jay Ashworth wrote: > So, should browsers send absolute host names in http/1.1 requests, and > shouldn't servers strip the trailing dot if they get one? > > I vote No and Yes, resp. The first question is tough, only because of the depth of the exatblished convention. I think I would argue 'Yes', as to remove ambiguity, but that naively makes a lot of legacy software trip in unexpected ways. As for the second question, I generally disapprove of throwing away information, so I say No. Clearly I like to make trouble for myself. :) -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Fri, Feb 22, 2013 at 05:21:02PM -0500, Jay Ashworth wrote: > In short, "yes, Jay, I do". Got it. :-) :) > You saw Joe's second reply? Apparently, I lost track of that while writing this up. :) -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote: > My snap reaction is to say that nothing should ever be *trying* to > compare a rooted F.Q.D.N. against a certificate; it is, as has been > noted, merely command line/entry field shorthand to tell the local > resolver where to quit; applications should all be stripping that > trailing dot. > > Do you have evidence that the extra AltName with the trailing dot > is operationally necessary? 'Necessary' is what's hard to ascertain here. If, under a UNIX-like operating system, you request a PTR with some command-line tool such as 'dig', you'll get a rooted domain name: $ dig -x 8.8.8.8 +short google-public-dns-a.google.com. And you can use this rooted domain name get an A record: $ dig a google-public-dns-a.google.com. +short 8.8.8.8 As a matter of example, if you had automation that was internally testing your network for trusted certificates, and generated a set of hostnames based on reverse DNS, then your SSL client will now be using rooted domain names. When I did my initial development with OpenSSL, I observed: - If I did not have the rooted domain name in the SAN, then any SSL client stack would fail the verification if a rooted domain name was used to connect to the SSL server. - I could generate a CSR with both formats of hostnames. - My OpenSSL-based CA (and our internal MS-based CA) would sign said certificate request, preserving all of the hostnames in the SAN. - and now using a roted domain name was successful. And I figured, if both OpenSSL and Microsoft's Certificate Services, (and their respective SSL clients) behaved the same way, I just coded my automated generation of the CSR to include the rooted domain names, just to cover my bases. I did not expect that misc commercial entities would punish people under these circumstances... Now, I expect in this specific customer's case, I'm reasonably certain that they won't have a tool chain / work flow / whatever, that would introduce a rooted domain name. But, I don't know if I can guarantee that for all of our current and future clients. I don't know if the practices suggested by RFC 1535 will come into effect, but I wanted to future-proof our product in this regard... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > -- Brian Reichert BSD admin/developer at large
Re: looking for terminology recommendations concerning non-rooted FQDNs
On Fri, Feb 22, 2013 at 05:19:03PM +1100, Karl Auer wrote: > It's a convention common enough and useful enough that I can see why > people would want a handy term for it. The core issue I'm trying to resolve surrounds the generation of a CSR. We're trying automate this process for a network appliance my employer sells. When our appliance generates a CSR for itself, among the steps is to get a PTR record; by convention (or otherwise) these are rooted domain names. When we generate a CSR, we're choosing to include the rooted domain name, as well as the other form (for now, I guess it should be called a FQDN, the version without the trailing dot). The resulting issued certificate has both forms in the SubjectAltName field, and this allows both hostname forms to be used to establish an SSL connection to our server. They are considered distinct for the Subject verification phase. It's come to my attention that some commercial certificate vendors think that having multiple hostnames in the SAN list costs more money; go figure. Our customers then have to go through some soul-searching to pare down the list of hostnames in the SAN in the CSR. There's some understandable questions about why we include both forms, and whether or not they are necessary. We need to document our policies and recommendations, and I'm trying to establish the vocabulary. Hence my original question. Irrespective of the state of RFCs, there are competing conventions, and ambiguous terminology. And I was seeking guidance. :) I do appreciate the feedback provided thus far. > Regards, K. > > -- > ~~~ > Karl Auer (ka...@biplane.com.au) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog -- Brian Reichert BSD admin/developer at large
looking for terminology recommendations concerning non-rooted FQDNs
I'm trying to nail down some terminology for doc purposes.
The issue: most resources on the net freely describe a fully-qualified
domian name ('FQDN') as to exclude the root domain; i.e, they exclude
the trailing dot as mandated by some RFCs such as RFC 1535:
http://www.ietf.org/rfc/rfc1535.txt
An absolute "rooted" FQDN is of the format {name}{.} A non
"rooted" domain name is of the format {name}
I'm trying to come up with some human-facing terminology that names
these two forms:
"a.b.c."
"a.b.c"
Many resources on the net use the term 'rooted domain name' for the
former, but they're collectively ambigious about what the other
form should be called.
Does anyone here have any solid advice, or can point me to a resource
that would call out useful conventions?
This was all fueled by Microsoft's client code apparently stripping
the root domain from PTR record results; I'm separately trying to
track down why that's occuring...
--
Brian Reichert
BSD admin/developer at large
Re: Telus mail server admin
On Sat, Oct 08, 2011 at 04:58:09AM -, John Levine wrote: > >That's nice for you, but some of us are stuck with a corporate policy > >that requires us to use such disclaimers, or face disciplinary actions. > > Not to seem unsympathetic or anything, but it's not my problem if your > management are idiots. I, for one, never use a corporate account to access mailing lists. My career has spanned many jobs, and I prefer to have a contiguous footprint that _I_ control... > R's, > John -- Brian Reichert BSD admin/developer at large
seeking pointers on the topic of 'name server registration'
I posted this request in another forum, but didn't get as much info as I'd hoped: http://article.gmane.org/gmane.org.operators.internet-access/5568/match=nameserver+registration To reprise in _this_ forum: I apologize for the noise; I hope this is an appropriate forum. I've been hosting DNS for years for several domains. Recently, I have had to rename/renumber my primary servers, and need to update various registrars of these changes. Most registrars seem fine with me just supplying the names of the new nameservers; they chase the A records, and generate the glue records, and off I go. One of these registrars (NetSol) introduces a topic I've never been aware of before, this concept of 'name server registration'. Web searching shows me several hits along the lines of 'how to register namesevers with registrar X', but I can't find a treatment of: - Is this anything more than generating glue records? - Why is this explicit step neccessary for some registrars, but not others? I'd appreciate any advice... -- Brian Reichert BSD admin/developer at large
Re: non operational question related to IP
On Mon, Nov 22, 2010 at 12:56:00PM -0700, Matlock, Kenneth L wrote: > 'Octal' (Base-8) :) > > The leading '0' is telling the box to interpret it as octal instead of > decimal or hex. My guess you're seeing an interface that uses inet_addr() instead of inet_pton(); the latter is used more nowadays at it supports both IPv4 and IPv6 addressing schemes. Whereas I've seen this behavior with a lot of vendors, I'm tempted to call it a bug: The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition http://www.opengroup.org/onlinepubs/009695399/functions/inet_ntop.html inet_pton(): If the af argument of inet_pton() is AF_INET, the src string shall be in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where "ddd" is a one to three digit decimal number between 0 and 255 (see inet_addr()). No mention of dotted quad being anything other than 'decimal', much less getting cute about guessing the radix. The *BSD manpages for inet_pton() call out a similar constraint: http://www.freebsd.org/cgi/man.cgi?query=inet_aton&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html STANDARDS The inet_ntop() and inet_pton() functions conform to X/Open Networking Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not accept 1-, 2-, or 3-part dotted addresses; all four parts must be specified and are interpreted only as decimal values. This is a narrower input set than that accepted by inet_aton(). As does Linux(): http://www.kernel.org/doc/man-pages/online/pages/man3/inet_pton.3.html AF_INET src points to a character string containing an IPv4 network address in dotted-decimal format, "ddd.ddd.ddd.ddd", ... RFC 2553 also calls out the non-decimal interpretation as being 'non-standard': http://www.ietf.org/rfc/rfc2553.txt If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. Note that many implementations of the existing inet_addr() and inet_aton() functions accept nonstandard input: octal numbers, hexadecimal numbers, and fewer than four numbers. inet_pton() does not accept these formats. Etc. I've never been happy with inconsistencies in serializing data structures... > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlo...@exempla.org -- Brian Reichert 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large
Re: Wireless STM-1 link
On Thu, Sep 10, 2009 at 11:55:40AM +0200, Rens wrote: > All the interfaces are forced to 1Gbps and full duplex. I thought that with 1000T, you need to keep autonegotiation in place: http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/ "A major problem is that many people are also hard setting Gigabit Ethernet , and this is causing major problems. Gigabit Ethernet must have auto-negotiation ENABLED to allow negotiation of master / slave PHY relationship for clocking at the physical layer. Without negotiation the line clock will not establish correctly and physical layers problems can result." Further: http://en.wikipedia.org/wiki/Autonegotiation "The debatable portions of the autonegotiation specifications were eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation protocol was significantly extended by IEEE 802.3ab, which specified the protocol for gigabit Ethernet, making autonegotiation mandatory for 1000BASE-T gigabit Ethernet over copper." Note the 'mandatory'... -- Brian Reichert 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large
