Saturday, 26 August 2017

Wireshark Traps For Young Players

I ran into an interesting problem in work today.  An Ethernet switch appeared not to be behaving correctly: frames that I know were being received on an 802.1q trunk (coming in from a WAN carrier) weren't being sent out an access port for no reason I could see.  The switch configuration was fine...there was no obvious reason it shouldn't have been working.

A bit of background.  

The IEEE 802.1q header has a bit in it call the CFI bit.  CFI stands for "Canonical Format Indicator". It is (or was) used to distinguish between Ethernet-format MAC addresses ("canonical") and Token Ring-format MAC addresses ("non-canonical").  Basically, this bit is set to 0 on Ethernet frames and 1 on Token Ring frames.  Since Token Ring is (mercifully) now a thing of the dim-and-distant past, this bit is now always set to 0 (which is why most people - including me - have never noticed it and may be oblivious to its existence).  The 802.1q standard specifies that frames received with the CFI bit set (indicating Token Ring frames) should not be transmitted on untagged Ethernet interfaces (because the MAC address format is different and won't make any sense).  This will become important later.

The more recent 802.1ad specification which - among other things - codifies "Q-in-Q" (a.k.a. double-tagging) renames and repurposes this bit so it is now called the DEI bit.  This is where my problems started, but more on that later.  DEI stands for "Discard Eligible Indicator" and is a hint that this packet can be discarded in the event of congestion on a link.  It is in the same bit position as the CFI bit just has a completely different meaning now.  

This gets me to my first problem.  I was told that my carrier was sending me tagged frames with the DEI bit set (there was a legitimate reason for this).  I figured that my Ethernet switch might interpret the DEI bit as a CFI bit (remember, same bit position in the 802.1q header) and might (correctly, from its point of view) refuse to send the frame on an untagged Ethernet interface.  Sure enough, once the carrier stopped setting the DEI bit, everything started working OK.

That would be the end of the story except that when I ran packet-captures to see what was what was going on, the frames coming in from the carrier had the DEI bit clear.  I can think of a few possibilities:-

  • My tip-off that the carrier was setting the DEI was incorrect and there was something else going on. Not likely since the problem went away as soon as the carrier changed this (and my theory around this seemed pretty sound).
  • The interface-mirroring on the switch was "lying" about the CFI/DEI bit being set (which didn't seem hugely likely either)
  • There was a problem with my packet-captures.

After some research, I found this (short but very informative) thread  The TL;DR version is that the Linux kernel "abuses" the CFI/DEI bit for its own internal purposes and always clears it !  This was fine when the bit was CFI (and therefore always 0), but it is distinctly not fine now that the bit should be interpreted as DEI.  As it happened, I had done all of my packet-captures on Linux machines 😞

So I set up an experiment.  I have a machine transmitting Ethernet frames (using this with with the following characteristics:-
  • IEEE 802.1q encapsulation (Ethertype 0x8100)
  • VLAN tag 120
  • CFI bit in the 802.1q header set to 1
Then I used Wireshark to capture these frames on a few platforms.  The results were eye-opening.


Sure enough, the 802.1q header and the VLAN tag are there, but the CFI/DEI bit is set to 0.  Bingo !!


The second packet-capture is done on the same NIC on the same laptop (it dual-boots Windows and Linux)

Even worse !!  Under Windows, I don't even get to the the 802.1q header.  I tried this on two different Windows machines (both Windows 10, admittedly) with the same results.  This could really send you off on a wild goose-chase if you were trying to troubleshoot a real problem.


Perfect: I can see the 802.1q header and the CFI/DEI bit is still set to 1, just as it should be.

The message thread indicates that this only happens with if the Ethertype value is 0x8100 (802.1q) or 0x88a8 (802.1ad) but not if another Ethertype is used.  Let's try that:-

Look at that !  Changing the Ethertype from 0x8100 to 0x8101 and now the Linux laptop leaves the CFI/DEI bit untouched (I had to twist Wireshark's arm to get it to parse 0x8101 as an 802.1q frame).  That makes sense: the Linux kernel no longer sees the frame as an 802.1q/802.1ad frame and therefore doesn't see the following two bytes as an 802.1q/802.1ad header that it can mess with.

The first lesson is that one needs to be very circumspect about packet-captures unless you are very sure about the behaviour of the platform you are doing the capturing on.

Second, if you have a WAN provider setting that DEI bit (e.g. on a "best-effort" WAN service), be aware that your switch may be refuse to pass those frames through.

Monday, 13 June 2016

ATX Bench Power Supply Status LED

Like lots of electronics hobbyists, I have an old ATX power supply salvaged from a PC that I use as a bench power supply.  It cost practically nothing and it works well enough.

However, like any self-respecting geek, I can't look at anything for any length of time without thinking of ways it could be improved. The target of my ruminations today is that LED in the centre of the picture. It was originally wired to that it would glow dimly when the PSU was in "standby" mode (i.e. connected to the mains, but not supplying output to the front panel) and brightly when the PSU was turned on.  This was easy to do (see below), but not a good idea.  It was practically impossible to tell at a glance whether the LED was "bright" or "dim".  It was just crying out to be changed.

Among other things, the ATX power supply outputs two useful signals:-
  • 5VSB : 5V standby, a low-current 5V source that is available when the rest of the power-supply is in standby mode.  This is on the purple wire of the ATX connector.
  • PWR_OK: A logic-level signal that goes high when the power supply has turned on and stabilised. This is on the grey wire of the ATX connector.
In my original version, I simply wired both of these to a red LED via two different resistors: 4.7K on the 5VSB line and 470Ω+1N4148 diode on the PWR_OK line.  If only the 5VSB line was powered, the LED glowed dimly (through the 4.7K resistor) but if both were high then the LED was powered via the 470Ω resistor and glowed more brightly.  The 1N4148 diode on the PWR_OK line was there to stop it sinking the current from the 5VSB line if it went properly low.

I decided I wanted to use a multicolour LED instead, red for "standby" and green for "on".  Here is what I came up with:-

When the power supply is in "standby" mode (5VSB on, PWR_OK off), current flows from 5VSB, through the red LED and R3 and hits the drain of Q2.  Because PWR_OK is low Q1 is switched off and its drain (and therefore the gate of Q2) is sitting at about 2-3V (the 5V from 5VSB minus the voltage drop through the green LED.  This is enough to turn on Q2 (which has a typical gate threshold voltage of 2.1V), so the red LED lights.  Virtually no current flows through the green LED to the gate of Q2, so it stays off.

When the power supply is turned on, the PWR_OK signal is asserted.  This turns on Q1 causing its drain voltage to drop to near ground.  This has the effect of turning on the green LED while simultaneously pulling the voltage at the gate of Q2 to ground, causing it (and therefore the RED LED) to turn off.

The 100K resistors are really precautionary: the gates of the MOSFETs draw no current at all.  They are only there to limit current if a MOSFET dies in a way that shorts its gate to ground.  They could be omitted and the circuit would still work just fine.

The whole thing fitted onto a bit of perfboard around 25mm2 which was encased in some transparent shrink-wrap. Its not pretty but it works well:-

There may well be better ways of doing this (suggestions welcome in the comments below).

Friday, 20 May 2016

Crimp vs Solder...fight !

For a project I'm working on, I have a requirement to butt-join some power cables together.  I have been soldering them, but for reasons that needn't detain us here they are an awful pain in the ass to solder.  I wondered was there any downside to using butt-splice connectors like these

My concern was that the contact resistance might be significantly higher than for a soldered joint leading to a significant voltage drop across them (they will be carrying a fair amount of current from a 3.3V power supply).  Time to do some testing.

I started out with four pieces of wire of (approximately) equal length. Three of them I cut in half and then joined back together using one of those butt-splice connectors, a solder joint or a simple twist. The fourth piece of wire I didn't cut: it will serve as the control.

So what is the resistance of each of these?  It is going to be pretty low no matter what, so a four-wire measurement is going to be needed. Happily, I have a 5.5 digit multimeter that does have four-wire resistance measurement capability.

This is what the test setup looks like. One pair of multimeter leads provides the test current and the other pair senses the voltage across the joint.

The results were pretty good:-

Joint TypeMeasured Resistance (mΩ)
Uncut Wire8

Treating the uncut wire as a control, that means that there is only around 2-4mΩ of contact resistance regardless of what method is used.  I have to admit, that's a good bit less than I was expecting.  There is also less difference between the solder joint and the butt-splice joint than I had expected.

As a secondary check, I also measured the voltage drop across the joint while running a decently-high current through it.  My bench power supply can supply a current-limited 5.8A.  Knowing this and measuring the voltage drop across the joint is a secondary way of measuring the contact resistance. Here are the results:-

Joint TypeMeasured Voltage Drop (mV)Calculated Resistance (mΩ)
Uncut Wire20.43.47

Curiously, the uncut wire measures a little higher than the solder joint. My suspicion is that the current-limiting on my (el-cheapo) power-supply isn't that rigid and it was letting a little more current through as it warmed up.  This is borne out by the fact that the last digit on the ammeter showed the current climbing just a little as the tests went on (just a few tens of mA over the course of the tests) and I did the test with the uncut wire first.  I could have controlled for this by monitoring current with a external - more accurate - ammeter, but I didn't and I think the discrepancy is small enough to ignore (for my purposes, anyway). If anyone is interested in seeing the test repeated a little more rigorously, I do have enough equipment to do it: leave a comment below and I'll redo the test.

I think the takeaway is that a solder joint is a little better than a crimped butt-splice joint, but not by a whole lot.  There are certainly factors that I haven't taken into consideration here: will a solder joint age better than a crimped-on connector (I rather suspect it will)?  Which one is mechanically more stable (again, my money is on the solder joint)?  These don't matter in my particular application so - happily - the result is that I should be able to use the much-easier-to-make butt-joint method for joining the cables I need to join.  A win !!

Monday, 29 February 2016

Proportional Representation in Ireland

I am not connected with politics or constitutional law in any way. I wrote this page really as an excuse to study up on something I found interesting. I have done my best to ensure that the content is accurate but if you do find any glaring errors please let me know and I will correct them. If you have any general comments/observations/suggestions about the page, I'd love to hear those also. Thanks.


Since achieving independence in 1921, we in Ireland have elected members to The Dail (one of our Houses of Parliament) using a system of voting called Single Transferrable Vote (article 16, section 2, subsection 6 of The Constitution). The purpose of this page is to explain exactly how this system works, to explain why many political scientists regard it as one of the fairest systems for conducting elections and to examine some of the mathematical anomalies which can arise from it.

Single Transferrable Vote

The basic idea underlying the Single Transferable Vote system of Proportional Representation is that any votes a candidate receives over and above the minimum necessary to be elected should not be wasted. Rather, the voters should be allowed to rank the candidates in order of preference, and any surplus votes a candidate has after being elected should be distributed to the remaining candidates in proportion to the next-highest preferences expressed by each voter.

Some history of the system to go here !

How It Works

The Vote

Voting is simplicity itself. The ballot paper will look something like this:-

Byrne, Gay
Independent Candidate
Haughey, Charles J.
Fine Gael
Lawler, Liam
Progressive Democrats
McGonigle, Eamonn
The All Night Party

The voter simply writes a number beside each of the candidates (or as many candidates as they wish) indicating the order of preference. The voter's favourite candidate will get a preference of 1, the second favourite will get a preference of 2 and so on.

Determination of the Quota

Once the voting is complete, the process of counting the votes begins. The first step is to determine the quota. This is the minimum number of votes which would be sufficient to elect only the desired number of candidates. It is a factor of

  • The number of votes cast
  • The number of people who are to be elected
It is calculated by taking the number of votes cast, dividing this by (1 + the number of seats to be filled), adding 1 to this result and discarding any fractional part. So in an area where 10,000 votes were cast and there are 2 seats, the quota would be 3,334 (= 10000 ÷ (1 + 2) + 1). It should be clear that with only 10,000 votes, it is possible for two candidates to obtain 3,334 votes, but not possible for three.

The First Count

During the first count, all of the first preference votes are counted. At the end of this, one of two things will have happened:-

Possibility #1: One or more of the candidates has reached the quota

These candidates are elected. The next step is to distribute their surplus votes (the number of votes they received over and above the quota). The idea is that these "spare" votes should not be wasted and should be transferrable to the voters' second choices

Possibility #2: None of the candidates has reached the quota

In this case, the candidate with the lowest number of votes after the first count and his/her votes are distributed to the voters' second preferences

Either way, the next step is to proceed to a second count for the purpose of distributing the surplus of the elected candidate or distributing the entire vote of the eliminated candidate.

The Distribution of the Surplus or The Elimination of the Lowest Ranking Candidate

Once a candidate is reaches the quota, any excess votes are distributed to the other candidates in proportion to the next preference votes of the elected candidate. A simple example: Assume that the quota is 3,334 (from our earlier example). Assume also, that candidate Charles J Haughey gets 4,000 votes on the first count. None of the other candidates reaches the quota at this stage. He is deemed to be elected and a second count begins for the purpose of redistributing Charlie's surplus.

At the end of the second count, it turns out that of those 4,000 voters who gave Charlie their first preference, 2,000 gave their second preference to Liam Lawler, 1,500 gave their second preference to Gay Byrne, 400 gave their second preference to Eamonn McGonigle and the remaining 100 didn't express a second preference at all.

Since the quota is 3,334, Charlie has 666 surplus votes to distribute (= 4,000 - 3,334). These will be distributed to the other candidates in the following proportions:-

CandidateTransfers from Charles Haughey
Liam Lawler(666 ÷ 4,000) × 2,000 = 333
Gay Byrne(666 ÷ 4,000) × 1,500 = 249
Eamonn McGonigle(666 ÷ 4,000) × 400 = 66

These transfers are added to each candidate's total from the first count. At this stage, the process begins again: If any candidate has now reached the quota, he/she is elected and another count begins for the purpose of distributing his/her surplus. If no candidate has reached the quota, the lowest candidate is eliminated and the next count will redistribute his/her vote to the next voters' next preferences.

There are some subtleties that arise in the distribution of quota which lead to a small element of randomness.  It can happen in three different circumstances, the most common of which is where voters haven't ranked all of the candidates (i.e. haven't written any number down against some candidates).  In that case, there may be excess votes available to be distributed (e.g. Charlie's surplus of 666) but some of those votes might not indicate a next preference.  Its probably not useful to delve into this in too much detail here: there is a very interesting analysis of this here, including an example (the Sligo-Leitrim constituency in the 1982 general election) where this randomness actually made a difference.

Interestingly, during Ireland's brief and ill-fated dalliance with electronic voting in 2002, the same random mechanism had to be built into the (electronic) counting system, even though a computer could have performed the count using a more accurate (but impractical for a manual count) system.

The Final Result

The final result is arrived at either when either:-

  • The desired number of candidates have reached the quota
  • The number of candidates remaining after the elimination of the lowest-scoring candidate at the end of a count equals the number of unfilled seats

This can happen because voters may not rank all of the candidates on the ballot paper. In our earlier example, the 100 voters who did not express a second preference will not have made any contribution to the second (or any subsequent) count.

But Is It Democratic...?

This system is regarded as among the fairest systems of the electoral systems in use in the world today. However, it is not without its imperfections. These are discussed in some length in put book reference here in considerable detail.

Wednesday, 14 January 2015

Fake MAX3232 RS232 line drivers ?

This is my second post about the plague of knock-off ICs.

The job was simple: I needed an RS232 interface on a Raspberry Pi so that I could use it to log console output from a misbehaving router (don't ask).  I could have picked up one of the millions of USB-to-RS232 converters on eBay (and run the gauntlet of FTDI's clone-bricking updates). However, I have read mixed reports of the stability of the drivers for these adapters in the Raspberry Pi kernel. Besides, there actually is a UART baked into the Pi SoC. The problem is that it only works at 3.3V logic levels so it can't be connected directly to a device that uses RS232 voltages. That's OK...I just picked up one of these and wired it to the appropriate GPIO pins on the Raspberry Pi's I/O connector

Its a simple device.  It converts between logic-levels (this version does either 5V or 3.3V)  on the pin-header and and RS232 voltage levels on the DB9 connector.  All that's on it is a MAX3232 line-driver and four ceramic capacitors (used by a charge-pump in the IC to generate RS232 voltages). It looks like the circuit (such as it is) is lifted directly from the IC's datasheet.

Simple, eh? No.  It worked just fine talking to a PC, but when I connected it to a Cisco 1841 router, very strange things happened.

When I sent a character from the Raspberry Pi to the router (I think I might have just hit carriage-return), this absolute explosion of characters was the result

Wow...what's going on here !  Out with the oscilloscope.  Here is an 'A' being sent from the Pi to the router:-

The blue trace is the Pi's TX line and the yellow trace is the Pi's RX line.  So far so good.  However, a few moments (about 68ms, to be exact) later, this happens:-

As far as I can see, what is happening is that when the Cisco echos back the character it received (yellow trace), there is crosstalk onto its RX (blue), so the router is seeing an "echo" of its own character (but corrupted).  The router echos that character back also, sees another "phantom" character on its RX etc etc.

As I mentioned, Raspberry Pi talking to a PC works just fine.  Sure enough, looking at that on the oscilloscope...

...there are little "spikes" evident on the Raspberry Pi TX line, but nothing like as bad and apparently not enough to cause a problem.

So the question was, where (and how) was the crosstalk happening ?  A few possibilities:-

  • Within the router itself (highly unlikely, or the router wouldn't work with a PC either and would be basically useless)
  • Within the console cable (that was my first theory when  was using a patch-cable, but I replaced that with a flat-8 cable which keeps the RX and TX lines separated by a few mm and that made no difference)
  • On the adapter board somewhere (most likely, but why, then, did I see hardly any crosstalk at all with the RPi talking to a PC or to a switch ?)

To test the theory that the crosstalk was happening on the adapter board, I disconnected the RX from the router from the TX line on the adapter board and used to oscilloscope to watch (a) the (now-disconnected) RX line from the router and (b) the TX line on adapter board separately.

Bingo !!  The line from the router was clean as a whistle (thus exonerating both the router and the console cable) but the TX line from the adapter (which shouldn't be generating any signal at all) was worse than ever:-

Yellow is the signal coming up from the router (console messages during the router boot sequence); blue is the output from the line-driver module (which should be completely flat).

I think it is a question of voltage.  The router uses a relatively high voltage on its TX line...around +/-10V.  Still perfectly within the RS232 specifications (which allows for  +/-12V) but higher than either a Cisco switch I tested or the PC use (both about +/-6V).  It looks like the higher voltage breaks down the line-driver.  Sure enough, conducting the same experiment with a switch instead of a router...

So it looks like the MAX3232 line-driver doesn't like +/- 10V on the RS232 side.  It should - according to the data-sheet it should be good for +/- 25V:-

I did one more test to confirm the theory: I put a couple of back-to-back 3.3V zener diodes in between the router TX and the adapter RX.  This has the effect of dropping the voltage that the adapter sees by about 4V.

Sure enough, the problem goes away (I didn't bother saving an oscilloscope trace but - trust me - it was perfect: no signal at all leaking onto the adapter TX). Its really looking like its the voltage that is causing the problem.

So at what voltage does the problem kick in? If I feed a square wave to the RX pin on RS232 side while watching what appears on the TX pin (nothing should) and gradually crank up the voltage, we should be able to find out.  In each of the screen-captures below, the yellow traces is the signal being fed to the RX pin and the blue trace is what is coming out of the TX pin.

Starting with 19.2V peak-to-peak...

No problem so far.  Increasing to 19.4V peak-to-peak...

...and 19.6V peak-to-peak... now we would probably be seeing problems.  Increasing the voltage to 20.6V peak-to-peak...

...and we would definitely be seeing problems.

If a real MAX3232 IC (mis)behaves like this, I'll eat my hat.  I have looked closely at the IC on the adapter and - to my untrained eye - it looks fine (decent enough quality moulding, quality of laser etching looks OK) but I'm willing to bet that these are fakes.

I would really love to get a known-genuine MAX3232 IC from a reputable supplier and use it to replace the suspect one on the adapter, but they only seem to be available in quantities of 2500 (at about €1 each).  Sorry, but I'm just not that interested.  However, if someone wants to send me a few genuine MAX3232s (you will need to pinkie-swear that they are definitely the real thing) I'll be happy to do the test and report the results here.

PS: An interesting thing I learnt in the course of doing this project is that the Raspberry Pi (the Raspbian image, anyway) runs a serial console on its built-in UART. A serial terminal emulator connected at 115,200 baud will receive a login prompt through which you can log in to the Raspberry Pi.  You never know when that will come in handy.

Tuesday, 13 January 2015

Spot the Chinese knock-off.

The IC on the top is the genuine article (its an LED driver). It costs about €10 (+VAT) from a reputable supplier in small quantities (down from nearly €20 a couple of years ago). The IC on the bottom came from eBay. I got ten of them for €3.09. Not €3.09 each...€3.09 for all ten.

Although you can't see it (because the quality of the laser etching is terrible and I couldn't get it to photograph), it has the Maxim logo (rough around the edges if you look closely), the same part number and at a glance looks like the real deal. Its only when you compare them side-by-side that you notice that the knock-off is physically smaller (that's not an optical actually is smaller), has poorer quality legs, poorer plastic encasing and the laser etching is nothing like as good. More pertinently, at first it didn't work in the circuit I put it into where the real one did (although, to be fair, I was playing a tiny bit fast-and-loose with the power-supply decoupling: once I fixed that, the knock-off worked just fine).

If you can't trust randomly-selected eBay sellers in the Orient who can you trust? It makes me wonder if that €30 Rolex I got is real.

Monday, 12 January 2015

Where does Blogger store pictures?

They say that a picture tells a thousand words.  Imagine my dismay, then, when I noticed that all of the pictures from my recent blog posts (all the ones I had created since switching to Blogger, actually) had vanished.  Thousands and thousands of my bons mots lost to the Internet.  Not since the burning of the library in Alexandria has such a misfortune been visited upon the store of human knowledge.

Thankfully, I had copies of most of the missing pictures and they have been restored to their rightful place, but I'm still not completely sure what happened. It turns out that photos you upload directly to Blogspot are actually stored in Google Plus (used to be on Picasa).  It is possible that I did a bit of a clear-out of my Google Plus photos at some point and accidentally deleted them.  I don't remember doing it, but its the kind of thing I would do.

Anyway, this blog post is part warning, part experiment.  Here is a pretty picture:-

It is one of the first pictures I took with my Nikon D50 when I got it almost 10 years ago. Its a fantastic camera and is still my weapon of choice when I need the best possible image quality. It still beats the socks off any other camera I have for image quality and speed (but not portability!).

However, none of that is of any interest to you, the reader.  What is interesting is that I am going to go looking to see where in Google's universe it winds up.  I am also shortly going to delete the picture in Google+ to see what happens.  I'll update this post with my findings.

UPDATE 13/Jan/2015: OK...I have just deleted the picture using the "Photos" app on my Android phone.  So far, no ill-effects on this blog entry, but lets see what happens

UPDATE #2: It didn't happen straight away, but a little while (perhaps an hour) after I deleted the photo from my phone, it also disappeared from the blog. Im rather proud of the photo, so here's another copy of it.