FreeBSD: How git and OpenLDAP server can collide via openldap24-(sasl-)client

I’ve have been doing some progress on my journey with bare FreeBSD, the tutorials are good and provide reasonable defaults to get started quickly. I quicklygot both a poudriere package builder inside a VM of my workstation and ezjail up and running on a small homeserver with an Atom CPU (that is quite not that quick a building). I actually wanted some extra switches enabled in my self-built packages not present in the binaries frome from

One jail would become a testbed for OpenLDAP I configured poudriere to build net/openldap24-server (default, except with SASL as enabled in i.e. Debian)  and since I like and use: devel/git (default). When I wanted to install git AND the OpenLDAP package in this jail, pkg  ended ith an obscure message telling me that files in openldap24-client conflicted with openldap24-sasl-client. Following the dependencies I tried to find the cause of the dependency conflict:

  • devel/git depends on  ftp/curl (default)
  • ftp/curl was (non-standard) configured to support LDAP and LDAPS since I want to play with LDAP:
    • That is what caused a dependency on openldap24-client for git.
    • Most other packages will do so once LDAP/LDAPS support is enabled (i.e. php5) – not on openldap-sasl-client.
  • net/openldap24-server with SASL results
    • in a package called openldap24-sasl-server (not openldap24-server!)
    • in a dependency of the server package depending on openldap24-sasl-client
  • Both openldap24-sasl-client got built and openldap24-client were almost identical (beyond SASL-support) and thus they conflict since they provide the same thing

I wanted SASL support but also git and curl. For whatever reason to fix this was to change make.conf as follows:


Using poudriere and a build jail called 10amd64, this was in: /usr/local/etc/poudriere.d/10amd64-make.conf.  Afterwards I (preferred to) completely rebuild all  package to make sure all package would take that switch (with -c):

poudriere -f /path/to/list-of-pkgs -j 10amd64 -c

Afterwards on the destined ldap server  both git and openldap-(sasl)-server now depended on openldap-sasl-client and could be installed alongside:

 # pkg install git openldap-sasl-server
Updating repository catalogue
The following 19 packages will be installed:

        Installing cyrus-sasl: 2.1.26_3 [1Labs]
        Installing openldap-sasl-client: 2.4.38 [1Labs]
        Installing curl: 7.33.0_1 [1Labs]
        Installing openldap-sasl-server: 2.4.38 [1Labs]
        Installing git: [1Labs]

The installation will require 279 MB more space

20 MB to be downloaded

Proceed with installing packages [y/N]:y

Unfortunately I wasn’t able to quickly find a reliable source why that switch has to be placed or is more closely explained. It can be found in a couple of packages, likely someon with more thorough FreeBSD experience would be able to bring a correct cause. It thoug causes packages with LDAP dependency to move their dependency from the normal to the sasl-enabled OpenLDAP client. At least, once I found about WANT_OPENLDAP_SASL, finding others who had this issue wasn’t difficult at all, i.e.

December 9, 2013

Posted In: Uncategorized

Tags: , , ,

Leave a Comment

Bootstrap pkgng without answering “y”

As per FreeBSD 8.4 9.2 and 10.0 (BETA as of writing) pkg will start replacing the old pkg_* tools, but the installed pkg command is only a bootstrapping command that downloads a current version of pkg and install it.
I like pkg, and coming from Debian apt-get and Redhat yum, the old pkg_* tools looked a bit – let’s say “rough” – while pkg looks and behaves quite familiar after using apt and yum.

I was looking for bootstrapping pkg (inside a ezjail flavour) without having to hit the ‘y’ each and every time. I was pointed to a very simple solution:

env ASSUME_ALWAYS=YES pkg bootstrap

Sometimes it’s just a matter of a) thorougly reading a manpage and b) put the pieces (switches, variables) correctly together.
Thanks Mat Arnold on this place for the right hint!

December 5, 2013

Posted In: Uncategorized

Tags: ,

Leave a Comment

Atom D510: FreeBSD cpu scaling, temperature and the non-existing C-states

A D510MO board was lying in the shelves and I decided to give a try for some FreeBSD testing. One topic I wanted to check out was power saving and getting to know. Most CPUs nowadays (even the now dated D510 Atom) support frequency scaling and most often C-States. Without digging into the details of FreeBSD’s ‘powerd’ enabling basic frequency scaling works as simple as adding the following line to /etc/rc.conf


sysctl can tell us what frequencies the CPU can work at ans the current freqency:

# sysctl dev.cpu | grep freq
dev.cpu.0.freq: 208
dev.cpu.0.freq_levels: 1666/-1 1457/-1 1249/-1 1041/-1 833/-1 624/-1 416/-1 208/-1

Now to check if the frequency scaling was working, hitting the CPU with some load was required, but where to take? On Windows a pretty simple tip taken from old journals was to fire up the system calculator app in scientific mode and let it calculcate very large factorials (german: Fakultät) like 999999999999! which will load the CPU and cause some heating in order to verify how loud a system can become – or in this case: Cause the CPU frequency to go up under load and scale down when back idle. It turns out FreeBSD base ships a with console-based calculator  called bc (on most Linuxes it’s GNU bc) which according to this yet old but still working article in Linux journal allows exactly this with a factorial function:

# bc
define f(x) {
 if (x <= 1) return (1);
 return (x*f(x-1));


In parallel on a second terminal execute “powerd -v” to see how the frequency goes up and down:

# powerd -v
powerd: unable to determine AC line status
[... system is idle, starting bc in the meantime ...]
load   0%, current freq  208 MHz ( 7), wanted freq  208 MHz
load   0%, current freq  208 MHz ( 7), wanted freq  208 MHz
load   4%, current freq  208 MHz ( 7), wanted freq  208 MHz
load  38%, current freq  416 MHz ( 6), wanted freq  261 MHz
load 141%, current freq  416 MHz ( 6), wanted freq 1044 MHz
changing clock speed from 416 MHz to 1249 MHz
load 100%, current freq 1457 MHz ( 1), wanted freq 3332 MHz
changing clock speed from 1457 MHz to 1666 MHz
load  93%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 101%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
[ ... bc is running and now gets stopped ...]
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load  68%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 3227 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 3126 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 3028 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 1453 MHz
changing clock speed from 1666 MHz to 1457 MHz
load   0%, current freq 1457 MHz ( 1), wanted freq 1407 MHz
load   0%, current freq 1457 MHz ( 1), wanted freq 1238 MHz
changing clock speed from 1457 MHz to 1249 MHz
load   0%, current freq 1249 MHz ( 2), wanted freq 1199 MHz
[... we see all supported clock speeds freq_levels passing by]
load   0%, current freq  416 MHz ( 6), wanted freq  208 MHz
changing clock speed from 416 MHz to 208 MHz
load   6%, current freq  208 MHz ( 7), wanted freq  208 MHz

This little experiment show that powerd is not that agressive when slowing the frequency back down as quickly as it rushes up, maybe tha its something to tune more aggressively on laptops.

Temperature readings

For CPU temperatures it happens to be as simple as loading the ‘coretemp’ module via kldload coretemp. Adding coretemp_load=”YES” to /boot/loader.conf enables the module ad system start. Afterwards CPU temperatures were readable via sysctl too:

# sysctl dev.cpu | grep temperature
dev.cpu.0.temperature: 44.0C
dev.cpu.1.temperature: 44.0C
dev.cpu.2.temperature: 41.0C
dev.cpu.3.temperature: 42.0C


Now most CPUs also support C-States to send to sleep when possible which would be actually quite good for power saving. In FreeBSD it seems sysctl can be used to query what C-states the CPU cores support via dev.cpu.<id>.cx_supported i.e.

# sysctl dev.cpu.1
dev.cpu.1.cx_supported: C1/1/3
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% last 58973us

Technically this would suggest that the CPU has the capability to use C3 but the current lowest C-State would be C1? I tried sysctl dev.cpu.1.cx_lowest=C3 as well as the global hw.acpi.cpu.cx_lowest=C3 (for boot this would be put in /etc/syctl.conf) but allas it remained always using 1 C-State.

It seems the Atom D510 is one of those low-end CPUs that do not support C-States anyway as per I’ve come across this thanks to FreeBSD PR 160561 where a very similar D525 was reported.
Possibly the CPU isn’t telling correctly about its supported C-states allas.

This was done on FreeBSD 10-BETA3 btw.

November 7, 2013

Posted In: Uncategorized

Tags: , ,

Leave a Comment

FreeRADIUS: Omit PAP auth passwords leaking to logs

hWhen using remote authentication on switches, most will primarly support PAP, the simplest method. This way the password is sent MD5 encrypted (to my knowledge) via the shared secret between the NAS and the RADIUS server. Nowadays this isn’t considered to be secure, nonetheless I don’t expect most devices to support RADSEC when the don’t do it already to today. Anyhow, one misconfiguration I ran into was that I saw my own password leaked in plaintext to logfiles only when loggin into a switch, not using PEAP-MSCHAPv2 via WLAN

The log lines of a successful PEAP-MSCHAPv2 login (Wireless LAN) don’t leak problematic information:

Sun Oct 13 10:22:07 2013 : Auth: Login OK: [username/<via Auth-Type = EAP>] (from client wifi-aps 0 via TLS tunnel)
Sun Oct 13 10:22:08 2013 : Auth: Login OK: [username/<via Auth-Type = EAP>] (from client wifi-aps 0 cli <MAC-address>)

The second line is due to “use_tunneled_reply = yes” which is helpful for accounting since otherwise the outer tunnel doesn’t get much useful data when users use an anonymous outer identity. However when authentication requests get logged from a PAP authentication, things look quite bad:

Sun Oct 13 11:21:41 2013 : Auth: Login OK: [myadmin/myPasswordInPlaintext] (from client switches port 0)

The cause was that I enabled logging authentication requests, where default is set to no (likely for performance reasons):


log {


        #  Log authentication requests to the log file.
        #  allowed values: {no, yes}
        auth = yes


The solution I found via the FreeRADIUS list archives was actually simple, the default (on Debian) is to log good and bad passwords – but that’s only happening if you log authentication requests. Thus: when logging auth requests and with  PAP – don’t forget to disable good and bad passwords logging!

log {
        #  Log passwords with the authentication requests.
        #  auth_badpass  - logs password if it's rejected
        #  auth_goodpass - logs password if it's correct
        #  allowed values: {no, yes}
        auth_badpass = no
        auth_goodpass = no



October 24, 2013

Posted In: Uncategorized


Leave a Comment

Nintendo GameCube opening

Now for something off-topic for this blog, but I’ve been a bit into retro gaming with some of my friends namely on the old Sony PSone (the last, much slimmed down version of the PlayStation 1). Lately I’ve aquired a GameCube with a working GameBoy Player – which apparently seems to be one of the best variants playing GB, GBC and GB Advance games on large screens. Unfortunately the cube was previously owned by a heavy smoker, and electronics exposed to nicotine tends to really smell bad *yuk*. It needed a full cleaning, which required a full teardown and massive cleaning. However…


While Sony’s PSOne can be easily disassembled and cleaned using standard Philipps screwdrivers, Nintendo isn’t playing as nice with us. They use special, sometimes even proprietary screws to make their devices tamper proof.  Apparently beyond tamper-proof torx found on some XBox and PlayStation (2/3) consoles, Nintendo doesn’t like us fixing our consoles and uses rare and off-standard screws. Getting these screwdrivers is possible nowadays thanks to Internet, but often cheap screwdriver specially sold as Nintendo screwdriver kits are made of so poor quality that they I read often they were not  worth your time and money.



Nintendo uses Tri-Wing (also TriWing) screws  all over the places like even back to the first GameBoys, even the GameCube controllers have them. At least this is a standards-based screw type, you can get them, but due to its finicky design, the fins of the wings break quickly on the cheap tools.  I needed Y0 and Y1 sizes sometimes which are also found as #0 and #1. If you are into lots of repairs consider a high quality tool like the Wera 375 TRI-WING screwdrivers. Although mine are not from Wera, I do have use some of their screwdrivers and they are of very good and long-lasting build quality.

The “GameBit”


When it comes to NES, SNES or the GameCube, Nintendo is doing even better: The main screws to open thee console use a screw  type that is completely non-standard. A smaller, yet similar, one is often found on things like original Gameboy cartridges.  The closest standard screw type could be a called a reverse or inverted Torx screw. Thanks to Nintendos’ wide use of these screw types, they’ve beoame known under the name of GameBit since they are mostly only seen on Nintendo gaming equipment.

The gamebit screws are quite finicky and if the screwdriver bit is of cheap quality, the screws quickly take damage. Unfortunately cheap gamebits tend to be very badly molded or just to weak for longer use. One gamebit kit that I’ve seen getting good reviews (and that I can now confirm) are the gamebits from Rewind Bits.

Happy Nintendo fixing!

P.S. Yes the GameCube mentioned in the beginning has been fully cleaned by now, it still works and luckily almost doesn’t smell anymore.

September 13, 2013

Posted In: Uncategorized

One Comment

A FreeRADIUS for your Switch authentication

As previously blogged, I wanted to share and comment a sample config – where I use ntlm_auth for authentication against AD and LDAP for authorization of Administrators, this was done using FreeRADIUS 2.1.12 on Debian wheezy (7.x). Remember to do your own reading. I found “FreeRADIUS Beginner’s Guide” over at PacktPub to be a very good read to get a better understanding of FreeRADIUS and overall AAA concepts.


  • Show an example of a (then-working) FR virtual server for (Netgear) CLI authentication.
  • Have some explanation why I did things this way or not 😉
  • I derived from the preinstalled default server config and shrinked it to the minimum required
  • For the Samba / Winbind configuration, consider the Book at PacktPub or look at Alan Dekok’s
  • I use a non-standard port since another (main) RADIUS server is already listening on UDP 1812
  • Uses PAP since that’s what the switch only does. PAP sends plaintext password, but AD doesn’t have the plaintext password stored – blimey. We need ntlm_auth from Samba to do the check for us.

The server config is located in /etc/freeradius/sites-available and has to be symlinked to sites-enabled, but before doing so, youneed to

  • Configure Samba and Winbind, join the box to your Domain
  • Configure ntlm_auth module
    • ntlm_auth binary path
    • ntlm_auth’s domain

These parts can be found on, then you might want to do rememeber / adapt to AD specific behaviour:

  • Modify the LDAP module to support AD nested groups if your users are not direct members (thanks Nasser Heidari):
    • groupmembership_filter = "(&(objectcategory=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))"
  • Check, that your user group you want to query is NOT the primary group of your admin users since that doesn’t appear in the memberOf attribute .
    (if you are a LDAP magician and know a trick, let me know)

Anyway, let’s get started with the server:

server netdevices {

listen {
        ipaddr =
        port = 41812
        type = auth

# local test listener for debug of this virtual server
listen {
        ipaddr =
        port = 41812
        type = auth

Then the authorize section basically tells the server:

  • To use PAP (some switch vendors support (MS)CHAP but Broadcom FASTPATH only does PAP, so we can disable all the rest
  • If no Auth-Type was sent, update the control to use our own ntlm_auth that will be defined in authenticate.
authorize {
        #  If you are using multiple kinds of realms, you probably
        #  want to set "ignore_null = yes" for all of them.
        #  Otherwise, when the first style of realm doesn't match,
        #  the other styles won't be checked.


        # Most switches support PAP only
        #  This module should be listed last, so that the other modules
        #  get a chance to set Auth-Type for themselves.

        # If no Auth-Type was sent, we assume PAP but that we should
        # use ntlm_auth for AD authentication through ntlm_auth.
        if(!control:Auth-Type) {
                update control {
                        Auth-Type = "ntlm_auth"

The authenticate section is quite simple but we need to tell the server that it can use ntlm_auth, at the end. You’ll need to adapt /etc/freeradius/modules/ntlm_auth.

authenticate {
        # For PAP against AD with ntlm_auth we need to
        # let Samba ntlm_auth do the authentication work.
        Auth-Type NTLM_AUTH {

        # For local users with plaintext password we can still use LDAP
        # Reminder - you might disable update conrol in such casse in
        # authorize because it's an unconditinal update.
        Auth-Type PAP {

Most of the “magic” is finally done in the post-auth section:

  • Check if the user is in the required LDAP group, else reject
    • In AD I experienced problems with primary group memberships since they’re not written in memberOf Attributes
  • If it is an admin user, update the reply with the Netgear/Fastpath-specific AVpairs so the switch knows that it’s an administrative user
  • The remaining is from the default config, I’m not sure if we need it to work correctly.
#  Post-Authentication
#  Once we KNOW that the user has been authenticated, there are
#  additional steps we can take.
post-auth {
        # Only Domain admins are allowed, don't use the german group
        # name due to encoding issues
        if (LDAP-Group == "Network-Admins") {
                # Getting authorized requires informing the
                # (Netgear) device about privilege level.
                # Depending on the config only with this additional
                # reply message one gets authorized as admin on the shell.

                # Both seemed to work on Netgear 10.0.x,
                # Administrative-User is more vendor-neutral.

                update reply {
                        Service-Type = Administrative-User
                        Cisco-AVpair = "shell:priv-lvl=15"


        # No-one else is allowed.
        else {

        # For Exec-Program and Exec-Program-Wait

        #  Access-Reject packets are sent through the REJECT sub-section of the
        #  post-auth section.
        #  Add the ldap module name (or instance) if you have set
        #  'edir_account_policy_check = yes' in the ldap module configuration
        Post-Auth-Type REJECT {
                # log failed authentications in SQL, too.
#               sql


Done, now symlink your config to /etc/freeradius/sites-enabled and start FreeRADIUS (as recommended for testing) in debug mode (service freeradius stop, then freeradius -X)
If everything went ok, you should now be able to authenticate against your Switch SSH and the Web-UI, as well as getting authorized for administration.

August 29, 2013

Posted In: Uncategorized



Admin login through RADIUS on Netgear managed

When I had already dived into RADIUS for wireless network authentication, authorization (and accounting) – AAA – I started to think that it was worth to tinker about moving admin authentication of @work switches to RADIUS too. Netgear managed switches definitely support this – unfortunately neither their Websites, KB, nor the (mostly quite good) Software Administration Manuals for firmware 8.0 and 10.0 mention real-life configuration examples – only 802.1x port authentication.

I had to get inspired by comparing Cisco, Dell PowerConnect (see “P.S.”) documentation and blog post but in the end I hope this make sense for you too:


First things first, define a local admin password and enable password (if your policy or you want to have it

(switch) #enable password
(switch) #configure
(switch) (Config)#username admin password

Then enter the RADIUS server configuration – and prepare authentication via RADIUS where Netger uses a concept of lists that contain methods of authentication (very close to Cisco IOS too). The first method will be use as long as it does not time out, I put local in there in case no RADIUS server is available. But since my environment was small and I wanted to keep the config files as small as possible I stuck to the default lists which for SSH and Telnet is the ‘networkList’.

(switch) (Config)#radius server host auth <ip|name> port 41812
(switch) (Config)#radius server key auth <ip|name>

(switch) (Config)#aaa authentication login "networkList" radius local

Still not getting to privileged mode?

The 10.x-based Netgears should let you authenticate with any user the RADIUS server allows to access, yet it doesn’t allow you to privileged exec mode other than with the local enable password. Here you have at least 3 options where for 2 of them I know how to achieve them:

Use a global enable admin (1)

You can configure ‘enableList’ (or create a enable List on your own) to do radius auth, but then it will ask your Server to verify a user called $enab15$ user (this is actually documented in the CLI manual). Obviously the point of having personal admin acccounts is to have shared global admin passwords agains. This works and is documented in the CLI manual personally but I don’t really like this idea.

Tell the switch that about being an administrative user (2 & 3)

Then you can configure your RADIUS server to inform the switch via additional reply message: “this is an admin, let him/her to privileged mode”. For Netgear the message is Service-Type = Administrative-User – finding this out was possible thanks to similarities with Dell PowerConnect and by trying it out.

(2) If you have your own lists you’ll have to figure out how to configure the switch to work correctly but in case you use the default lists (3), you have to tell your switch to interpret the additional message with:

(switch) (Config)#aaa authorization exec default radius local

For the Web-UI this additional reply message from the RADIUS server is (interestingly!) not required for the Web-UI. Any user your RADIUS-Server sedns “Access-Accept” gets full access to the Web-UI. (I’ll re-check this) Make sure you only let members of your admin group pass at the level of the RADIUS server. If you are ok with this, you only have to tell http method to use radius too:

(switch) (Config)#ip https authentication radius local

Obviously you can send cisco-avpair = “shell:priv-lvl=15” which is what you can do with Cisco Switches – the advantage being that you (should) be able to more granuarly pass privilege level although I haven’t investigated what the different privilege levels other than 15 (admin) means on Netgear.

Finally on 10.x the serial ports (line console) don’t use networkList by default but defaultList – by modifying networkList you obviously leave console to local authentication only – what’s your though on this? If I have physical access to the device should I make it possible to silently try and error network admin passwords or should I make things consistent for all logins?


Differences to pre-10.x firmware

For Firmware 8.0-based switches that can’t be updated to 10.x firmware things are a bit different – and likely 9.0 too according to CLI manuals. I didn’t have any’ 9.x available as all have been legit for 10.x upgrade).  The ‘aaa authorizaion’ command didn’t exist back then. Instead of this, create an authentication list and map it to the ssh method. The additionnal message from your RADIUS server thereafter is sufficient to get to enable mode.

aaa auhentication login mylist radius local
line ssh
(switch) >login authentication mylist

Difference in enable behaviour

Both 8.x/9.x and 10.x will happily pass you to privileged exec mode on a CLI with following differences (with this config, YMMV)

  • 10.x will put you directly into privileged exec mode (Prompt: hostname) #) if it has received Service-Type= Administrative-User
  • 8.x/9.x will continue asking for the enable command but let you pass without additional password query
  • 10.x will NOT let you in without this message – even if the RADIUS-Server has sent ‘Access-Accept’
  • 8.x/9.x will let any user to CLI for which it has received an “Access-Accept” – but it will deny privileged exec mode without receiving the additional message from the RADIUS server:
(8.x-switch) >enable

Access Denied! You are not authorized to enter into Privilege mode!

In a later post I’ll jot down a sample configuration for basic switch admin authentication for FreeRADIUS, note that Netgears only do the most basic RADIUS authentication method called PAP. With FreeRADIUS this requires you to have passwords store in cleartext in your password database  (which is not what AD does but NT hashes) – but there is a workaround for this dilemma at least with AD.


P.S. The chances are good that if you have some Dell PowerConnect switches and yet see FASTPATH mentioned in SNMP MIBs, Manuals etc. or you think that the syntax looks very close to Netgear – yes both are running on the same Broadcom FASTPATH software (based on some embedded Linux kernel).

July 16, 2013

Posted In: Uncategorized

Tags: , , , ,

Leave a Comment

Monitoring Netgear Switches: Interesting MIBs

At my job we have been introducing new switches and in terms of feature’s and cost we’ve gone with Netgear. Sure every vendor does have it’s sharp edges, but so far mostly I’ve been quite happy with them. I’ve been thinkering around with how to monitor them – since they do SNMP I studied their MIBs and have found out some things that might help. One major disadvantage compared to big vendors is that far less companies use them in production and thus monitor them – I haven’t been able to find a specialized plugin that would cover Netgear-specific items so this Is a quite note on what I’ve been able to find. This only covers the fully managed switches, I don’t know if their smart managed switches also partially run on FASTPATH.

Netgear = Broadcom FASTPATH
The fist  and most obvious thing that I’ve found was that not only the chips inside Netgear managed switches are from Broadcom (as did 3Com) but also the operating systems, in fact the MIB namings suggest that Netgear buys the base (Linux-based) switching OS from Broadcom which is called FASTPATH ( According to Google search, some Dell switches are also known to run a some sort of Broadcom FASTPATH.

Getting the right MIBsBe sure to get a set of MIBs matching the closest possible to your revision you run onto. Netgear seems to modify behaviour (so did Cisco) or the meaning of values, so be sure you get the matching MIB for your product! At least the naming for MIB’s seemed to stay consistent though.

MIB 8.x to 9.x/10.x
While some of the (now) older switches run 8.x firmware I’ve realized that this revision (and likely previous releases too) tend to have meaning of output values. 9.x and 10.x based switches seem to be more consistent to each other but I wouldn’t warrant for that.

The most interesting parts are in private MIBs
I’ve been more interested in environmental and STP status and although Netgear seems to implement BRIDGE-MIB I had to realize that the most valuable information about STP is only exposed through their private MIBs:

If you look after monitoring STP status or checking some configurations for switching, this is the MIB you’ll want to check some examples that I’ve found useful:

  • agentStpAdminMod: Returns 1 when STP is enabled (I guess you don’t want that to be disabled!)
  • agentStpForceVersion: Returns the configured STP mode Multiple, Rapid or even plain ol’ STP
  • agentStpCstPortForwardingState: Followed by .<ifIndex> it gives you the current forwarding state of an (R)STP port
  • agentStpMstPortForwardingState: Gives meaningful values about the switch in case you’r using MSTP

This is the MIB that has environmental values,  this shows to have stong differences between 8.x and 9.x/10.x based firmware so pay attention. For sure a GSM5212P (12-Port GE) doesn’t have the same (amount) of Fans than GSM7228P (Stackable 24 GE + 1 10GE)

Unfortunately on most models I’ve encountered, some OIDs are not meaningful (buggy?) and thus can’t be used for monitoring, either way, here are some OID I’ve found interesting:

  • boxServicesFanItemState: Depending on the model you’ll almost certainly have .1 as the first fan. Some switches have 2-3 or more fans so be sure to check .1.-n
  • boxServicesFanSpeed: Most often bogus as it seems (9.x)
  • boxServicesPowSupplyItemState: While .1 tends to be the main PSU, .2 tends to be the RPS connector (not present by default)
  • boxServicesTempSensorState: Some devices have more than .1 sensors, do a walkd to find it out.

As for Nagios or Icigina I haven’t been able to find plugins to monitor Netgear boxes I guess I’ll have to write my own checks. I hope to post some examples here.

May 6, 2013

Posted In: Uncategorized

Tags: , , ,


On Jumbo frames: Short note about iSCSI

It’s been a bit of time since I’ve had to deploy a new iSCSI target at work, this time it was a QNAP box that will serve as secondary backup target for some Backup Exec.

As you have hopefully read elsewhere if using iSCSI, be it over 1GE or 10GE: Use Jumbo or Giant frames for better efficiency. If your target has the capacity to fill the pipe, it will do better if you use Jumbo frames.

On the HP-3Com 2928* I’ve been using for iSCSI, I never had to bother anything about Jumbo Frames, things just worked after enabling Jumbo Frames on both target- an initiator-side NICs. As I’ve had to learn the hard way: Jumbo Frames have to be enabled on a couple of switch vendors for at least I know now that this applies to both Netgear (Smart & fully) managed as well as Cisco gear. Without this you may be able to connect to the Target Portal, but at least the Windows Initiator bugged to hell, even hanged without being able to disconnect from a target – we had to kill the preferred targets and reboot the initiator side to get rid of the erroneous iSCSI session. After Jumbo Frames were being allowed on the switch, things started flowing without hickups.

For Netgear managed switches this is done on per port basis, according to manuals, this sets the maximum allowed MTU – without
knowing it better I allowed the maximum possible MTU the switches on 8.0.3.x Firmware allows:

interface 1/0/22
mtu 9216
copy system:running-config nvram:startup-config

Of your course you can also specify interface range xx/xx/xx yy/yy/yy and configure all ports you need to allow Jumbo Frames.
While a exported Text configuration on their smart switches shows the same statements you have to do this via the Web UI configuration, the result behaves the same as with the fully managed boxes.

For Cisco’s popular 3560, 3750 series and others apparently you set maximum MTU globally, here is the link to the IOS comands for MTU mangling.

* After the 3Com aquisition by HP, the 2900 series have been relabled twice, first as V1910 later 1910.
Apparently HP seems to care a bit about this line of Switches as they’ve received a fully IPv6 manageable Firmware in 2012  (even for our pre-HP era 3Com units) and stil receive regular bugfixes as of writing.

January 27, 2013

Posted In: Uncategorized

Leave a Comment

Serial console server (2): The curse of the 4 ports

As said in the previous post, the “fancy” EXSYS 8 port card got happily recognized, but: It only showed 4 of the total of 8 Ports, and that was only when the 2 onboard serial controllers were disabled. *grrr*

After trying out also Debian’s backport kernel without success I checked the 8250’s driver code in Linux and only later I stumbled upon Kyle Anderson’s wiki: Debian (and basically most Linux distributions) are hard coded not to initialize more than 4 serial ports, we need to tell it to do so via a boot paramter. Honestly: Most modern computers don’t even have physical serial ports, maxing out at 2 if they are still present, so this setting makes sense for most computers. Kyle’s Wiki contains instructions to get it running with CentOS which is using GRUB, Debian has switched to GRUB2 with squeeze so his instructions needed slight changes since grub/bootloader doesn’t exist and /boot/grub/menu.cfg gets overwritten at kernel updates.

Edit and change: /etc/default/grub as follows

# squeeze default:

# new:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash 8250.nr_uarts=8"

Then issue ‘update-grub’ and reboot, then check if you additional ports get regoznized by issuing:

cat /proc/tty/drivers

For some reasons, I had even to up this to 16 because when I enabled the first 2 onboard tty’s the first serial port of the EXSYS Oxford-based were not ttyS2-tty9, but ttyS5 -ttyS12 maybe due to other controller using resources. Since playing with kernel boot parameters doesn’t belong to my daily business I was very happy to find this “sidenote” saving me a couple of hours learning deeper into driver options.

September 11, 2012

Posted In: Uncategorized

Tags: , , ,

Leave a Comment