Friday, August 13, 2021

Grappling with Tech

 

It is sometimes said that we don’t choose technology, it chooses us. It is certainly possible to live in today’s world without a cell phone, a computer, or a car but it would require individuality and resolve. Whether you are an early adopter, a late-comer, or a total Luddite, sooner or later technology will hunt you down.


Technology and culture have a difficult relationship. The latter, comprised as it is of large numbers of human beings, is fundamentally resistant to change. Technology, on the other hand, is initially driven by a much smaller subset of entrepreneurial folks who embrace change as a way of life.


Consider the automobile. Fred Flintstone notwithstanding, Carl Benz’s 1886 US Patent 37435 for a gas-engine-powered vehicle is often referred to as the birth certificate of the car. Early autos were noisy, unreliable, fume-spewing contraptions that threatened the existing equine transportation system more by scaring the animals than by providing a superior alternative. By 1913, Henry Ford’s mass-produced Model T was affordable, reliable, and easy to operate. Before long the roads were paved, and hitching posts were becoming scarce.


In the beginning, it was more than enough that you had four wheels and an engine. Once auto-tech had asserted itself into the culture, it began to differentiate. Somewhat ironically, horsepower was the motivating factor for some, while others preferred fuel economy. More recently, environmental impact and safety have taken the driver’s seat. Although growling engines and gas mileage would appear to be at odds, technology was ready with a solution.


Premium sound systems had long been a thing in cars, but soon the output switched from Rock and Roll on the inside to a throaty growl out the tailpipe. Stomping on the gas pedal of your F-150 would once again summon the mating call of power and performance. Propulsion systems continued to get quieter – almost eerily so with electric vehicles - but in the interests of safety even those have been mandated to produce some sort of warning sound.


There are many pros and cons for buying a new versus a used car, but one irrefutable advantage of newness is that unmistakable new car smell. While automobile manufacturers have sought ways to prolong the original aroma, third-party vendors have come forward with various imitation fragrances. You could add new car smell to your 10-year-old Honda, but it would be wrong.


But new car smell isn’t the only aromatic issue surrounding automobile technology. Fearing that some gearheads would pass up electric vehicles due to the absence of gasoline smell, Ford is now offering Mach-Eau. You might think that avoiding odoriferous gas stations would be a driving force behind electric vehicle adoption, but for 1 in 5 drivers it’s just the opposite. While no one expected the very first cars to smell like a horse, some contemporary buyers see Mach-Eau as a game changer.


Wrestling with the sensory issues of sounds and smells is one part of taming automobile technology, but what about the changes we can’t distinguish? Expanding driver awareness with proximity sensors and backup cameras was straightforward enough, but now we have progressed to Traffic Aware Cruise Control and Automatic Lane Centering. These additions seem innocent, until you realize that the car’s speed and direction are being controlled, albeit to a limited degree, by the onboard computer. It only seems logical that if the car can see what human drivers see, it should be able to make decisions like, or perhaps better than, humans do.


Now in the early stages of development, full self-driving computer algorithms will eventually control our cars and obsolete human driving skills altogether. Only a select few will understand how these proprietary AI systems work – the rest of us will be trusting our lives to an anonymous software development team. The auto technology of the future may console us with whatever sound and smell we choose, but how it will transport us is anyone’s guess.


Let the grappling begin.


Author Profile - Paul W. Smith - leader, educator, technologist, writer - has a lifelong interest in the countless ways that technology changes the course of our journey through life. In addition to being a regular contributor to NetworkDataPedia, he maintains the website Technology for the Journey and occasionally writes for Blogcritics. Paul has over 40 years of experience in research and advanced development for companies ranging from small startups to industry leaders. His other passion is teaching - he is a former Adjunct Professor of Mechanical Engineering at the Colorado School of Mines. Paul holds a doctorate in Applied Mechanics from the California Institute of Technology, as well as Bachelor’s and Master’s Degrees in Mechanical Engineering from the University of California, Santa Barbara.

Monday, August 9, 2021

Flashback: Which port is he on ??

 I run into this quite often where the client isn't sure which port the client is connected to.

In many cases, I do not have access to their network management system, or the network is down or worse, the documentation is dated and inaccurate. I think every network analyst should know how to do basic tasks like this one.


in some scenarios, I use Wireshark and capture a CDP packet to which switch, port, vlan, etc... or if I have a tool like a NetAlly Linkrunner.


In this example, I show you how to do it on a Cisco 2940, but you will find that this works on most models.



Thursday, August 5, 2021

Troubleshooting with the Time Column in Wireshark (chris greer)

 Hey Packet People!


Learning how to use the time column goes a long way when troubleshooting network issues. It is very important for analysts to learn how to configure it to represent time in different ways, start and stop time references, and to add specific TCP timers.


In this video we will show how to get the most out of the time column. Download the pcap in the video description and follow along!



Tuesday, August 3, 2021

Layer 1 – gets them all the time

 I was doing some work on-site when the client asks me if I can help with his IP cameras.

The vendor helped over the phone and they determined that 2 cameras probably need to be replaced. The client explained that he is not that technical and wanted someone else to take a look before he goes through all the trouble of taking them down and sending them back.

I started with a quick look around and determined that the camera is POE and the cable runs to a patch panel, then to the DVR, which is also providing the POE.


The Video monitoring software did indeed show that the 2 cameras were down and not reachable and we could not ping them. The client went on about configuration, resetting to default, etc.… and then I simply suggested, “have you tried moving the camera to another port to ensure that the DVR ports are all ok”. He replies yes and said, “Great show me how you did it”. Yup, he was correct, so I noticed that obviously, the camera was not reachable regardless of which DVR port we used.


So then I reached into my bag to take out my netAlly Link Runner G2

(https://www.netally.com/products/linkrunnerg2/) and tested using


the cable from the DVR to the camera. I have provided the link so you can check it out if you’re interested since I don’t sell them 😉. The tester immediately showed that pin 3 had a short. We already swapped out and tested the patch cable several times, so I took a better look at the patch panel and what do you know, pin 3 was either bent way back or broken.


We both looked at ourselves in complete surprise and a bit confused since we couldn’t figure out how that could have happened. So then we performed the same test on the other patch panel port and found the same thing. ???. Before he could ask, I told him that I’ve never seen that before.


Good thing we had enough slack on the back of the panel and spare ports. I simply re-punched the cables to 2 new/good ports and all is well.



Wednesday, July 28, 2021

Flashback: Wireshark's duration Option

 Learn how to use the tshark or dumpcap command line utility with the autostop duration parameter.

This is a helpful tip if you run tshark or dumpcap from the command line manually or via batch files and dont want to control how long the capture runs.



Popular post