I tend to toss CDs included with my electronic purchases as they usually only contain documentation or drivers already outdated by the time I purchase the product. It’s relatively easy to track down any manufacturer’s updated drivers and documentation. However, with Canon DSLRs the original CD-ROM is required to be inserted or the original utility required to be installed before you may upgrade to the latest version – what a pain. I found a fix that worked for me on Windows 7 (64-bit) and wanted to share the information. It’s a simple registry edit that adds several entries to emulate that which the Canon software would have created if you installed it from the CD. These are the registry entries that the upgrade files will look for before allowing the upgrade. Instructions:
I purchased the SuperMicro AOC-SASLP-MV8 SAS/SATA card to attach eight individual SATA hard drives in JBOD configuration running Windows 7 (64-bit). However, immediately upon installation of the drivers that were available on the included CD-ROM (220.127.116.11\amd64\) I was greeted by the dreaded Windows BSOD. The machine would BSOD and continuously reboot on subsequent reboots. I found that once I removed the 3TB drives from the system the system would boot correctly and did not experience blue screens. Through trial-and-error I found a fix which allows the controller to work with 3TB hard drives without experiencing BSOD. Note that there are two controllers with very similar model numbers. The firmware I loaded onto this model (AOC-SASLP-MV8 ) is reported to not work on the other (AOC-SAS2LP-MV8).
Relevant system specific information:
OS: Windows 7 (64-bit)
Card Model: AOC-SASLP-MV8
Firmware version shown in card bios upon arrival: 18.104.22.168
Confirming I have firmware 22.214.171.124 loaded onto the card, I updated the drivers from hdsentinel as they are not publicly available on SuperMicro’s FTP site for this card.
This new driver (126.96.36.1990) seemed to do the trick. Wanted to post this here as a reminder to myself and also to help others who don’t wish to scavenge for the working driver version. Big thanks to those who contributed to the avsforum thread regarding this issue.
I recently purchased a used Cisco Catalyst switch, and the previous owner didn’t bother to reset factory defaults before selling it. This meant I did not have the enable password to enter privileged mode. The following were the steps I used to reset the switch configuration.
Note: This tutorial was performed successfully on a Catalyst 2950. Reset process may vary depending on model.
- Disconnect power cable
- Hold down “MODE” button until STAT LED turns off
- Once your command prompt “switch” appears, you can type the following commands:
- Look for the configuration file in the list. The name should be something along the lines of config.text by default. Now you’re going to rename it so the switch will not see a configuration file at boot, and instead will prompt you to create a new one. Type the following:
rename flash:config.text flash:config.old
- Once the switch has reboot, you will be greeted with a configuration setup prompt. Type “
y” to begin basic setup.
- Once completed – type “
2” to save to nvram
Your switch should now load your new configuration.
I’ve found a few annoying issues while configuring my HTPC with XBMC – one being the X cursor re-appearing after long idle states. The cursor will go away after restarting XBMC, but this is annoying to do several times a day. The fix is quite simple – the steps are listed below.
sudo nano /etc/X11/xorg.conf
In the text editor – find the section of the file labeled Section “Device”. The ending of this section is simply EndSection. Add the following line before the EndSection statement:
Option "HWCursor" "false"
Simply restart X either by restarting XBMC or the machine completely. The cursor should now stay gone for good!
I ran into some issues while configuring my XBMC HTPC with HDMI audio. After some time with various troubleshooting steps I was able to repair the issue by completing the following steps:
Relevant system specific information:
OS: Ubuntu Desktop 11.04
HDMI Device: XFX ATI 5770
Ensure no devices are muted (indicated by “MM”).
sudo alsactl store 0
This step saves the running alsa configuration
sudo aplay -l
This command will list the installed alsa devices. Choose the device which you want to output the HDMI audio from – paying attention to the card number and device number.
card 1: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
The above information is used to configure a custom audio device within XBMC. Within the XBMC system configuration settings, change the output device and output passthrough device to custom with the following name:
plughw:1,3 (Note that yours may differ – it is based on the output of the aplay command.
After saving, restarting the machine, and re-launching XBMC, I was now receiving audio over HDMI – though sounds for the system menus no longer functioned (an issue I’ve since ignored). However, when I played audio, it did not seem as though I was receiving the center channel audio. I was able to fix this by an odd combination of configuration settings. While playing a video I set the audio to analog – changed the volume from -60db to 0db, and switched audio back to HDMI.
Another addition to my posts about Cisco ASA 5510 tasks. The following is to change the password for a user within the device. Simple and straight forward – but ensure that you backup your running configuration before making any system changes.
enable config t username USER password PASSWORDHERE privilege 0 write mem
Here’s a good article which covers Cisco Privileges.
Configuring SNMP on ASA 5510 is straight forward – but once again I prefer a more straight forward list of the commands vs. the verbose explanation by Cisco. See below to enable traps to a community name “SNMPCOMMUNITY”, the server IP being 192.168.1.1. As with any commands that creates changes to your device – ensure you backup before making any changes.
enable config t snmp-server host Inside 192.168.1.1 snmp-server community SNMPCOMMUNITY snmp-server enable traps snmp authentication linkup linkdown coldstart
That’s it! Thanks for reading.
Friends of mine have consistently heard my complaints about Mediacom’s overcrowded nodes which they neglect to split, the uncoordinated and unreliable customer service, and dangerously ignorant installers (hell, my Mediacom VoIP installer didn’t know what RJ-11 was as I discussed the install with him). However, with the current U.S. duopoly in regards to broadband – I’m forced to stick with it, as the DSL provider in the area is unable to provide more than a 1.5mbit line. I’ve tried to make peace with these existing issues, but this week I found yet another issue with Mediacom to add to my list – which I cannot accept.
I run a local DNS server on my network – and had made the decision to move away from Mediacom’s DNS servers as my forwarders after testing the speed of theirs in relation to the alternatives. I am in NO WAY directing my traffic toward the Mediacom DNS servers. This left me quite confused when I received a Mediacom re-direction page this week after typing a URL incorrectly. I hopped onto DSLReports and got the scoop. I found Mediacom has initiated a campaign to increase advertising revenue by automatically redirecting clients to their ad-based redirection site. The big problem I have with this is – they are completing this by means of deep packet inspection vs. re-directing through their internal DNS servers. This means it takes precendence over my valid DNS response from an alternative DNS server.
After 20 minutes on hold with Mediacom support, as is usual, customer support gave the same script about the ‘opt-out page’ and the directions to follow. He stated there is no way for them to verify (as the support offices) who has opted-out, and additionally informed me that it was tracked by the customer’s modem MAC address.
Unfortunately, for us Mediacom subscribers, we are at the mercy of Mediacom to ensure the opt-out is working correctly. This post’s purpose is little more than to rant about my own experience – but I hope that it can at least bring some additional attention to these obnoxious, and shady actions by Mediacom in recent months.
Forwarding logs from an ASA 5510 to an external syslog server is simple – but I can seldom find a straight forward list of commands for specific tasks for the ASA. So here it is – but note this is highly customizable:
logging enable logging timestamp logging trap notifications logging asdm notifications logging facility 23 logging device-id HOSTNAME logging host inside SYSLOG SERVER HOSTNAME OR IP logging debug-trace logging permit-hostdown
Here’s the syslog section from Cisco’s site if you need more information.
Though us network nerds may work in a terminal most of the day – our workstations are largely Windows based. This is a quick guide to backing up a Cisco device configuration to a Windows machine. It’s fairly simple:
Download WinAgents TFTP Server Manager and run through the installation process. This will setup a tftp server on that Windows machine that you will use to direct the configuration to. Once installed, connect to the local server.
Once configuration is complete and you are connected to your machine – find the IP of the Windows workstation (we’ll need this in a moment).
Now, connect to the Cisco device. Login and also enter enable mode:
Once in enable mode, use the copy configuration using the following command:
copy startup-config tftp
You will be prompted for the server address. Type in the Windows workstation IP address here.
You will also be prompted for the name of which to save. I usually save this as the date and time of the configuration and save it in a folder for the device’s configuration backups – so do whatever method works for you.
Press ENTER and the transfer will begin. You should notice statistics on transfer are shown.
It’s that simple. I’ll use this post as a reference to some more in-depth Cisco blogs in the future – but wanted to state it in one place vs. repeating it in each post. Thanks for reading.
Wanted to give a shout-out to my new favorite podcast – Packet Pushers. With a lengthy commute every work day I listen to many technical podcasts. I’m a fan of most twit.tv shows such as TWIT, TWIG, etc. but they rarely cover anything about the in-depth networking topics I enjoy. Packet Pushers on the other hand is like sitting in on a group meet-up of “world-class” networking gurus and being able to absorb knowledge about the real networking world. I’m nowhere near the level of knowledge about the topics as the hosts – but it really allows me to escape to that networking side of my mind and take it all in. I recommend this to anyone interested in such topics, and if you read this blog in any sort of regularity – it probably means you. Check it out at packetpushers.net
I was working on a set of Ubuntu servers for a cluster in my network lab and wanted to look into alternative boot methods to streamline the process. I followed a lot of tutorials which recommended setting up a new DHCP server that could assign the machines leases and then direct the machines to the correct boot file. After some failed attempts with running a temporary DHCP and TFTP server on a Windows machine I sifted through my DHCP server settings for pfSense and found that it actually had support for network boot built in. This was great and allowed me to skip the whole DHCP server step and just change the following in the Services > DHCP Server tab in pfSense:
Of course for this to work I had to have pfSense’s DHCP server enabled. Having this setup will now allow the bootable machines to be assigned a DHCP lease then look for the TFTP server at the address specified (192.168.2.200 in my situation) and to look for pxelinux.0 to boot from. The next portion of this setup is a slightly modified version of the article found here https://help.ubuntu.com/community/PXEInstallServer , modified in the sense that I left out any DHCP server steps due to the fact that I’m handling the direction through pfSense.
Setting up your PXE server on Ubuntu:
sudo apt-get install inetutils-inetd tftpd-hpa sudo nano /etc/default/tftpd-hpa
Make sure this file looks like this:
#Defaults for tftpd-hpa RUN_DAEMON="yes" OPTIONS="-l -s /var/lib/tftpboot"
Save the file if you need to make any changes and restart the daemon:
sudo /etc/init.d/tftpd-hpa restart sudo nano /etc/inetd.conf
Edit the file so it looks similar to the following (note that you may need to change “udp” to “udp4” to override the default and use IPv4:
tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
Once completed editing this file we need to copy the boot files from the Ubuntu ISO or CD. In my case I inserted the Ubuntu Server CD into the machine’s drive and then completed the following:
sudo cp -r /media/cdrom/install/netboot/* /var/lib/tftpboot/
You can copy these files from wherever you’d like just as long as they end up in /var/lib/tftpboot/
At this point you should have everything in working order on the server side. If your NIC has a boot menu for network boot (as some of my Intel NICs do) you can go ahead and try booting to the network. If successful, it should retrieve the file from the server and then proceed to the Ubuntu Server installation screen. If you want to customize your boot from this point (for example, retrieving the files from a local CD instead of over the Ubuntu mirrors via HTTP) see the Ubuntu guide listed earlier.
Client Machine Setup Using gpxe:
I found that I had better results using gpxe on the client machines. I setup a boot floppy that included all of the NIC drivers by going to this website http://rom-o-matic.net/gpxe/gpxe-git/gpxe.git/contrib/rom-o-matic/ and choosing “all-drivers” and selecting a .dsk as the output format. There are many different options you can chose as well if you would rather use USB or CD for example. I created a floppy from this image using the following command:
dd if=IMAGE.dsk of=/dev/fd0
The example above assumes IMAGE.dsk is in the directory you issue this command from and also that your floppy drive is located at /dev/fd0.
This boot disk is quite useful if you are running into any issues. It has a menu with a few setup and diagnostic commands. You can manually set the server of which to direct once booted to this disk (if things don’t work for you automatically), change the target boot file, etc.
Hopefully this gets those interested in PXE boot going successfully. If you are having any problems, here are a few things to check:
- Check your DHCP server settings. Ensure that the IP address and filename is correct.
- Check all of the configuration files edited earlier in this guide. Any typos in the directory path will prevent things from working properly.
- Check that your PXE server is listening by issuing the following command:
netstat -a | grep tftp
- Check that your NIC supports PXE boot
- Check that you have properly enabled network boot in BIOS
If I’ve missed anything feel free to contact me and I’ll add any additional steps for setup or troubleshooting to the list.