It seemed like a good idea at the time.
Talking to Aastra tech support about a deployment issue with the 6757i, they requested a wireshark capture of the phone as it booted. Simple, right? I’ve used wireshark a lot through the years, and luckily for me, most of my use in the past has involved a linux router that I could run it on directly. I didn’t have to worry much about switches and taps. Not that I haven’t done that, too, just not for a while. Namely not before Gigabit Ethernet hit the scene.
There are articles by the ton about building a passive network tap, and I’ve even done it before, though it was about 8 or 10 years ago. Here are a few that I referenced:
So I dove in and built the tap, but no luck at all getting it going. I couldn’t see a thing. Then I discovered a comment on one of the (many) sites I was checking to try to learn more about why I wasn’t seeing anything on the taps. The comment basically said that Gigbit Ethernet is using both transmit and receive pairs in both directions simultaneously. There’s a DSP involved that subtracts the data you are sending (also any injected crosstalk) from the data you are receiving. So Gigabit Ethernet has much more going on than I realized. Also – no Gigbit passive taps. All Gigbit links will need an active tap or, as I had the advantage of using before, a bridged connection to use for the snooping.
So… I cheated. I knocked the port speed down to 100M long enough for the passive tap to show me what I needed.
In the interest of making the endpoint deployment easier, we are working toward this model:
- Unbox, assemble and install the phone.
- Phone’s first boot gets its IP from the data network VLAN, and gets config from TFTP assigning it to the appropriate voice VLAN and rebooting.
- Phone now boots into voice VLAN and gets IP and config server from the voice space. The TFTP config here kicks off the Aastra process that requests the extension and password and configures the phone.
Boom! Done. Sounds nice, eh? Here’s where we’re up a tree. I have the PBX-In-A-Flash server configured with an IP in both the data and voice VLANs, TFTP responding in both VLAN spaces, and the initial process works as you’d expect: Boot happens, grabs IP, grabs config, reboots, gets voice IP and does a firmware check, sees the new firmware in the voice TFTP space, installs new firmware, reboots, and then…..
Um… yeah. Then it continually reboots once it gets to the 50% checking for firmware point in the boot process. So you may see a “passive network tap
” writeup from me soon documenting what has already become somewhat of a circus trying to get what seemed like a simple wireshark capture. <sigh>
[UPDATE] Okay, here’s what I screwed up: I did not realize that the config COMPLETELY OVERWRITES any previous config. In other words, on initial boot I was telling the phone to go to the voice VLAN and reboot, and since I was assuming it was already configured for the voice VLAN, I was not adding those lines to the voice VLAN config file. So it would get the VLAN config from the data side and reboot, get the initial voice VLAN config and reboot… and find itself back in the data VLAN getting the voice VLAN assignment, etc. etc. Endless reboot, designed by yours truly. All I had to do all along was add the voice VLAN config to the final config on the voice side.
Deploying a multi-building, multi-campus VoIP telephone system using Asterisk.
Our university campus is working from a phones system older than most of the students attending here. There is little functionality (at least accessible to the end users) beyond the ability to answer calls and get voicemail at the phone. We’re moving toward a system that will allow us to take advantage of the technology available to us to both increase the utility of our campus telephony, and also greatly reduce the monthly expenditure on traditional PSTN connectivity. I intend to document most of the journey here in the hopes that it will prove useful to someone else with an equally challenging environment and set of goals. Continue reading