You are here: Home / Archives for apple

Screen and Reverse Telnet with Macbook Pro

September 6, 2011 by 2 Comments

As a lot of readers already know, from comments and discussions on other forums, I recently made the switch from PC to Mac for my main personal computer.  This wasn’t some sort of Microsoft-hating frenzy, but rather a case where I had more compelling reasons to use a Mac at home (Apple TV, iTunes, wife’s Mac, etc.) than I did to stick with the PC (games).  I still have the PC for when I get the gaming urge, but since most of my time these days is spent studying, gaming has taken a back burner for the foreseeable future.

I won’t bother you with my initial reactions to the Mac as they’ve been mostly positive and probably not entirely different than many other people’s experiences.  What I will say, though, is that as a long time user of various flavors of Unix, it’s nice to be operating on a platform that is Unix based again.  Specifically, it’s nice to not have to download bolt-on software in order to be able to use SSH, Finger, TFTP, etc.

One of the tools that I have used extensively in the past is GNU Screen.  For those unfamiliar with the program, you can check out a brief overview over at Wikipedia: http://en.wikipedia.org/wiki/GNU_Screen, or at the GNU Screen website here: http://www.gnu.org/software/screen/.

Despite using Screen since I was first introduced to it back around 1990 or so, if I recall correctly, I’ve only ever used it really for one thing: connecting from a Unix Machine to something using the serial port or a modem.  Even the modem bit I didn’t use all the time as I tended to favor Minicom.  So, when a couple of friends suggested that I use Screen for solving a problem I was having, it made sense.

As part of my Cisco lab I have some fourteen different devices that I need to access at any one time.  I have all of those devices set up to my main terminal server (3945 which is also my main a-lot-of-other-things as well) using reverse telnet.  In this way I can do a lot of things, but typically I would SSH to the terminal server, connect to a host by name, then use Ctrl-Shift-6 x to get back to the terminal server and do the same thing again for another host.

This is all made possible using an Async card:

NAME: "High Speed Wan Interface card with 16 RS232 async ports(HWIC-16A) on Slot 0 SubSlot 3", DESCR: "High Speed Wan Interface card with 16 RS232 async ports(HWIC-16A)"

 

With a pertinent configuration like so: 

interface Loopback0
ip address 172.16.0.1 255.255.255.0
ip host s2 2054 172.16.0.1
ip host s1 2053 172.16.0.1
ip host s4 2056 172.16.0.1
ip host s3 2055 172.16.0.1
ip host r5 2063 172.16.0.1
ip host r2 2060 172.16.0.1
ip host r6 2064 172.16.0.1
ip host r4 2062 172.16.0.1
ip host r3 2061 172.16.0.1
ip host r1 2059 172.16.0.1
ip host r8 2066 172.16.0.1
ip host r7 2065 172.16.0.1
ip host ASA 2051 172.16.0.1
ip host AP1 2052 172.16.0.1
ip host bb2 2057 172.16.0.1
ip host bb1 2058 172.16.0.1
line 0/3/0 0/3/15
session-timeout 120
no exec
transport input telnet

 

Still, opening fourteen hosts can get tedious, as you might imagine.

What this configuration also allows for, however, that I had only been using occasionally is logging in to any device by opening a telnet connection to the port.  So, I can either telnet to the parent device’s IP address (in this case it’s 10.7.68.221) or to the loopback address (if I have routing) and adding on the port number like so:

telnet 172.16.0.1 2056

 

which, as we see from above, would take me to the device labeled “s4”.   That’s all good, but still requires me to open each telnet session by hand, right?  Not necessarily: enter Screen and the magic of configuration files.

I have two configuration files for Screen: one is a .screenrc file which sits in my home directory as is standard on Unix systems.  Note that I could also put this in my /etc directory and change the name if I wanted a system-wide default for all users.  The other file is a custom one that I only use when I’m doing lab-work, and I call that one screen.ccie.

If I want to open just Screen by itself, from a terminal (I use iTerm2) I just type “screen –A” which opens up Screen with all possible emulations enabled (just in case).  If I want to open my ccie lab configuration I type “Screen –Ac screen.ccie” to reference the startup file.  I also use “screen –A /dev/tty.KeySpansomething” to use my USB/Serial adapter if I’m at the console somewhere.

Below you’ll find the screen.ccie file, with comments, as well as a screen shot of what it looks like in action.  I didn’t include the .screenrc file because it is identical, except for the last section that opens up all of the different telnet sessions.  I’m sure there are a lot of ways to do this, some better than others, and infinite combinations of colors, stats, etc. that can be configured, but this is what I have for now.

 

 

# SomeClown's .screenrc file.  Cribbed from a lot of places.
# Credit to both @IPv6Freely and @jay25f

# Next and Previous tabs shortcuts
bindkey "^e" next       # Next
bindkey "^w" prev       # Previous

# Various options
escape ^Zz                      # Control-A is needed elsewhere
nethack on                      # Just 'cuz
maptimeout 5            # Fixes Vi
vbell off                   # Pavlov
startup_message off     # Meh
defscrollback 30000     # Lots o' logging room
autodetach on           # Go away, come back.
shelltitle ""

# Status at bottom of screen; tabs, etc.  The code's a FusterCluck, but looks nice
hardstatus alwayslastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< %=%D %M %d %c"
hardstatus string '%{= kK}%-Lw%{= KW}%50>%n%f %t%{= kK}%+Lw%< %{=kG}%-= %d%M %c:%s%{-}'

# Specific for CCIE Lab.  Standard .screenrc file doesn't include text below

# Create named tabs for each device
screen -t Stuff 0                       # General
screen -t R1    1
screen -t R2    2
screen -t R3    3
screen -t R4    4
screen -t R5    5
screen -t R6    6
screen -t R7    7
screen -t R8    8
screen -t S1    9
screen -t S2    10
screen -t S3    11
screen -t S4    12

# For each tab above, do stuff
at R1 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2059 \015"
at R2 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2060 \015"
at R3 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2061 \015"
at R4 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2062 \015"
at R5 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2063 \015"
at R6 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2064 \015"
at R7 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2065 \015"
at R8 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2066 \015"
at S1 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2053 \015"
at S2 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2054 \015"
at S3 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2055 \015"
at S4 stuff " echo 'Starting some shite...' && sleep 10 && telnet 10.7.68.221 2056 \015"

Incoming search terms for the article:

Filed Under: Apple, Console, SSH, Telnet, Terminal Emulation, Tools Tagged With: , , , ,

Why Bonjour Hates my Wireless Network

January 27, 2011 by 13 Comments

Why Bonjour Hates my Wireless Network

Many of you know my struggle as of late to integrate all of my recently acquired Apple devices into my existing network.  Many of you also know the frustration I’ve had with this process and have been innocent passers-by to my incessant twitter updates, rants and spontaneous bursts of misplaced anger.  Here then, is my brief explanation of what the problem is, and why I now—after too many rabbit-hole adventures to list—believe that I will not solve my problem without different equipment or a radical re-design of my network.

I should point out, by the way, that it’s not that I’m a masochist—really I’m not—but rather that in my studies I find it useful to have a lot of equipment lying around.  That equipment inevitably works its way into my home network, and after some time I have a large and sometimes convoluted structure in place.  In this case, however, the wireless is pretty far outside the scope of anything I’ll deal with on the CCIE Routing and Switching Lab Exam, and was brought in specifically to support some future upgrades to my home: wireless security, roaming VoIP phones, etc.  The irony, as my wife so perfectly pointed out the other evening, is that if we just had a “regular” little wireless router “like all the normal, non-computer geek people” our Apple devices would all work.

If you haven’t read my previous posting on Bonjour, that might provide some more background but isn’t, strictly speaking, necessary.  Some understanding of Bonjour might be helpful, however, so very quickly, here it is: Bonjour is Apple’s implementation of a service discovery protocol similar to Microsoft’s zero-conf.  It uses a couple of addresses to make things work, and it is the protocol behind Apple’s “everything just works” magic.  If you want more than that, Google can offer you much deeper explanations.

Bonjour uses two addresses, really, to do its work: 224.0.0.251 and 224.0.0.252, the latter of which is the “discovery” part of the protocol and the former where the action happens.  The astute among you will notice that these are both link-local addresses and so won’t be forwarded by layer-3 devices (even really, really broken ones) at all.  I had already been around the block with this once before, and so figured that because my wireless network was one broadcast domain (thought I smugly) everything would be all good.  I was wrong.

Now would be a good time to toss in a quick network diagram so that you can visualize what we’re talking about here.  The drawing below is just the wireless portion of my network as it applies to what we’re discussing in this article.  Rest assured, there is a lot more out there, but none of it is applicable to this situation.

As you can hopefully see, we have a 2811 ISR connected to a 2950 switch via 802.1q, and two 1142 APs connected at layer-2 to the switch.  What might not be as obvious at first is that the Wireless Lan Controller you see at the upper right of the diagram is a module sitting in the 2811 router.  This is where the heart of evil apparently lies, but more on that in a minute.  The access points are on VLAN 16, and get DHCP assignment from the 2811 along with option 43 and option 60 which are both necessary (despite what you may hear) to get the radios registered to the controller, at least in this configuration.  All VLANs are allowed everywhere (for testing) and no ACL/VACLs or any other security outside of standard wireless is applied.

Before anyone points out the obvious, by the way, I did reconfigure this arrangement to put the APs on the same VLAN as the WLC management interface, make that the native VLAN all the way through, and bridge the switch and router at layer 2 with BVI, just as a test to eliminate layer-3 boundaries.  While interesting to do, that didn’t solve the problem we’re having here.  In fact, I didn’t even notice the real problem location until I made this diagram (who would have thought?).

The WLC modules that plug into a router, while running the same software and otherwise operating almost identically, are different in at least one key respect from their stand-alone counterparts: they can’t communicate at layer-2 with the router.  A standard controller (say a 4400 series) can communicate at layer-2 with radios plugged in to access switches, thereby becoming the first layer-3 hop from the radios—even when different VLANs are assigned than management.  The integrated module, however, communicates with the host router across the backplane at layer-3.  Looking back at the diagram, you can clearly see that drawn out.  So no matter what I do with bridging from the radios, switch, router, etc., inevitably I’ll have layer three separation between the radios and the controller.

This is all well and good for most protocols, but not for link-local multicast.

I think I found every rabbit-hole possible to get lost down, and proceeded to do just that.  When I finally ran out of said holes to explore, kind folks on twitter that I respect and look up to sent me off in still more directions.  I tried, in no particular order:

(1)    Using Destination NAT to change the 224.0.0.251 and 252 addresses to multicast in the 239.x.x.x range

(2)    Using Destination NAT to change the 224.0.0.251 and 252 addresses to unicast

(3)    Using helper maps

(4)    Bridging everything under the sun to everything under the moon.  No love because the backplane can’t be bridged.

I was going to even try GRE tunnels, DCI, or any other type of tunnel to move Layer-2 over Layer-3.  At the end of the day, however, besides getting tired of the project, I decided that nothing was likely to work.  Why?  Because one of the first things a layer-3 device does when it receives a packet is to decrement the TTL.  So no matter what I do with NAT, or tunnels, or any other damned thing, the router will always decrement the TTL before it decides to pass the packet to some other service (like DNAT, GRE, whatever), thereby discarding the packet before it ever reaches those processes.

As far as I can tell today, this is unsolvable.  Apple hates me, and others like me.  Using a TTL of 1 as your method of locking down communications is pretty rock-solid from a DRM viewpoint, but also very inflexible and heavy-handed.  I’m going to put a portable 3560 in my entertainment center to support my DirecTV box, Apple TV and other entertainment devices so that they can share the iTunes library on my main computer, but I’m not happy about it.  I lose my shiny N-connected coolness, and my iPad won’t be able to control those devices.  In addition, I’ve had to hard-set my wife’s printer, since her Mac can’t find it any more.

The bottom line is that all of the auto-configuration magic that Apple devices can have has gone away in my current set up.  I could fix it by running a parallel wireless network using autonomous access points, or buy a cheap-o wireless router, but then I have the other problem where I lose visibility and control, just to make a quirky system work.  The only viable option, really, is to change out my WLC module for a stand-alone controller—which I may do at some point—but at this point I’m tired and may just move on, defeated.

Incoming search terms for the article:

Filed Under: Apple, Bonjour, mDNS Tagged With: , , ,

iTunes Home Sharing

November 30, 2010 by 2 Comments

iTunes Home Sharing

A decent into the hell of Bonjour and black turtle-necks

This is just another short example in what I’m expecting will be a recurring theme here on Packet Queue: attention to detail.  As a network engineer, as in so many professions, paying attention to the little things can mean the difference between 10 minutes of troubleshooting and 3 days of unmitigated, sleep-deprived hell.  Luckily enough for me, the example I’m about to give wasn’t 3 days by any means, and since it was personal and not business the urgency wasn’t the same as if a WAN link had failed.  That said, I wanted it fixed.

My wife just bought a new computer—her first Mac since the original—and during the initial moving of files and such, I discovered a nifty feature of iTunes: Home Sharing.  Now, I have a large iTunes library at home already—something on the order of almost 180 Gigabytes—and wanted her to be able to share that library on her new Mac.  After all, we’re not pirates; we just want to have access to our shared music library on any computer or device in the house relatively seamlessly.  So I read a quick little blurb on the how-tos and why-fores of home sharing (real men sometimes read directions) and turned it on.  Aside from the crickets, nothing happened.  Sacrebleu!

Bonjour?

Bonjour! ¡No Hablo!

No, not a greeting but a name given by Apple to their zeroconf implementation that allows devices (printers, storage, shares, etc.) to auto-magically find one another.  This is the service that was supposed to make my iTunes library shareable between computers.  This is the service that was supposed to make everything in my dull world shiny again.  Not being overly steeped in the Apple world, however, has made me naturally suspicious of anything that “just works” as more often than not, said thing only “just works” if you “just use it in this one way”.  That natural suspicion of mine was proven to be well-founded.

Upon reading up on Bonjour, I discovered that it uses mDNS (multicast DNS) to find services.  Well, I thought, that would mean that multicast routing should work to fix my woes and I set off to work my magic.  Of course, I had missed a critical detail that would have saved me some time: the multicast DNS implementation that forms a part of Bonjour uses the multicast group address of 224.0.0.251.  If you haven’t noticed the problem yet, neither did I right away.  Had I noticed said problem, I wouldn’t have completely reconfigured my ASA and 2811 for multicast routing, and I wouldn’t have started tracing packets with WireShark:

The Multicast range runs from 224.0.0.0 through 239.255.255.255 as every first-year networking student probably knows.  But that range is like all other ranges and has certain reserved addresses within it.  In our case, the most interesting range is 224.0.0.0/24 which is known as the Local Network Control Block, or sometimes just Link-local.  Addresses in this range include the OSPF addresses of 224.0.0.5 and .6, and RIPv2 address of 224.0.0.9, among others. The salient detail being that these multicast addresses are typically sourced with a TTL of 1 and are not to be sent off of the broadcast domain in which they originate.

My wireless network, which my wife’s new Mac is on, is a different VLAN (and hence, different broadcast domain) from my wired network.  In fact, between my three wireless networks and multiple lab networks, my home environment probably has something on the order of 25 different broadcast domains.  Definitely not the norm for the average user, but also not uncommon if you start looking at more technical people or production environments.  So, the bottom line is that Bonjour and iTunes won’t work in my environment without an mDNS proxy or some other trickery.

What bothers me most about this revelation is that a lot of Apple’s software and peripherals work on this same system.  Airport (Apple’s wireless) as well as their printer setup, shares, etc. all work using Bonjour so are, from at least a simple viewpoint, broken across broadcast domains.  I’m guessing from Google searches and such that it’s a minority of users of iTunes who are concerned about this, and so it may not even make sense for Apple to address the problem.  But if you extrapolate that out to everything else using Bonjour, and consider a corporate network environment, I have to wonder how much of this contributes to Apple’s lack of penetration into enterprise networks.

As always, if I’ve gotten details wrong or you’d just like to offer your own opinion back and further the discussion, I can be reached here on this blog or via @someclown on Twitter.

Incoming search terms for the article:

Filed Under: Apple, Bonjour, Fail, iTunes, mDNS Tagged With: , , ,