When an engineer is booked to repair a fault, one of the options is a "co-op call".
This is where the engineer in question talks to our staff. It can be useful to confirm what we can see our end, and so can help the engineer do his job.
One of the rather odd things about this is the charging. Even though the term "co-op" seems to suggest a mutual benefit, or a two way thing, BT charge us £35 for the co-op call.
This makes no sense if we are helping the engineer do his job, surely it is mutually beneficial (so no charge) or we are providing consultancy (so we would charge BT).
What is stranger is the charge seems to apply even if it is found that the fault report and engineer visit was completely correct (i.e. a fault is found in the BT network and fixed). This especially makes no sense.
Even though this is rather odd, we have a specific field in the fault booking system to say if we are requesting a co-op call, and we always say "No".
Lately we have had the occasional call from an engineer, and helped them out, and to our surprise we have then had a bill from BT for co-op calls.
We explained that we did not request them, so "sod off", or words to that effect, but they are saying they have had a change of policy and now the engineer can request/make a co-op call whether we asked for one or not.
And, if the engineer makes a call, even when we said we do not want one, BT will charge us £35, even if the fault is found and fixed.
I'm sorry, but, basically, no way. This is so totally wrong it exceeds all of the other things that are wrong about BT engineer visits by orders of magnitude. It is quite unbelievable. It means BT can, if they wish, make £35 out of us for reporting a genuine fault in the service they provide and for which we pay. Even just calling to say "it seems to be working now" is £35. Actually making money from faults in their network.
So we have a plan, as always, and it is a voice warning on the contact number advising that the engineer should only proceed if he agrees to our terms for co-op calls, and to hang up otherwise. We'll record the call. The terms will be for BT plc to pay us for the call. I can't see that not standing up in court.
It does leave me wondering what the next cunning plan someone in BT will come up with to rip off its customers.
Lets be clear here - I really want to work with BT on fixing their systems. We need an attitude of working together to fix problems. Bullshit like this just alienates customers and makes it a battle with BT, when it should not be. Someone in BT needs to get some clue and stop the battle and actually think about providing a proper service and fixing it when it goes wrong. We have tried, and will continue to try and work with BT. I have personally joined in with an internal meeting with BT fault desk managers, given presentations, and spent the day with them. I really thought we were making progress, but once again it is all going downhill. Depressing.
2012-10-31
2012-10-30
Special Billing Investigation
So, BT are being fun. Things like agreeing a £144.00 charge last December was not valid but only crediting £137.80. No explanation.
Several of the other short paid agreed disputes are odd. E.g. £61 under credited, and now saying £11 will be credit but "£50 charge is valid". WTF?
So here is my response:-
As Stuart said, why are those charges valid?
Several of the other short paid agreed disputes are odd. E.g. £61 under credited, and now saying £11 will be credit but "£50 charge is valid". WTF?
So here is my response:-
As Stuart said, why are those charges valid?
You need to explain!
e.g. "Charge of £50 is valid"
What is the £50 for exactly, and why is it valid exactly?
You can't resolve a dispute simply by stating that "it is valid".
You need to elaborate...
If such a response was all that was needed then lets play that game.
In reply, I state "Charge of £50 is NOT valid". That all you need?
Or would you expect us to elaborate and back up that assertion?
Bear in mind that we never order end user premises module or co-op call module, ever. We do not order extra modules. It is hard coded in the XML ordering system to exclude these modules, and we have copies of the signed XML requests as well as the BT signed XML confirmations.
So if your logic is that some extra module was completed and so the charge is valid, you need to state that. We can then prove that we did not order the module and therefore that the charge is not valid.
As of 1st Nov we will charge BT for such investigation. That means you will have to provide evidence of your assertion that the charge is valid, such as sending a copy of the XML signed order. In the absence of such evidence the charge remains in dispute with us simply stating it is not valid.
If you don't have evidence to back up your claim, you can request that we investigate and find evidence for you. For example, we could provide a copy of the signed XML order and BT signed XML acknowledgement. This would prove the matter either way. We provide this additional investigation as a chargeable service, but free if we were wrong. Sounds familiar?
We call it a "Special Billing Investigation". It is a fixed cost of £144.00+VAT for all investigation relating to a single dispute item. It will involve work finding any supporting evidence relating to a dispute. The charge will be waived if we find that the BT charge being disputed is in fact valid (i.e. if we are wrong). You can order Special Billing Investigation from us by email, asking us to provide extra evidence relating to any disputed amount. I look forward to your order. The service starts on 1st November.
See the following web page for details of this service:-
Regards,
Adrian.
OSPF plodding on
Well, finally starting to get over my cold, and managed to get in early yesterday and today and spend a few hours on OSPF before the day starts.
I am still working on the database exchange process. I almost have it working (well, far end thinks we have done the exchange, so a start).
It is messy, but getting there. Once I have the database exchange sorted, I have to sort the "flooding" logic. This will then mean we have, and maintain, the OSPF link state advertisement database.
There are a few gotchas that I can see. The way entries are withdrawn is, err, fun. You mark them as old (a hour) and ensure everyone has seen that, then remove it. That is not too bad, but it is a problem if you want to change your mind and now announce the entry again. You sort of have to wait for it to all be removed before re-creating it. You are supposed to cater for a 32 bit sequence wrapping as well, in a similar way. There is another related gotcha in that you are not allowed to update an LSA more often that a certain rate. Well, what if you have changes faster than that? You are meant to delay them. That sort of means storing a current version, and a "new version" in the database and a process to pick up that we want to move to a new version after a delay. That sort of crap is horrid - who makes a protocol like that? Just saying in the text of the RFC "delay" sounds so simple doesn't it - but delay means storage and timers and tasks.
I suspect that I will have to have a pending "new version" for any LSA we originate, and a task to pick up when to move to it. Arrrrg!
So, next milestone is full database synchronisation, not just exchange and loading, but flooding (as designated router, backup router and other router).
Once the database synchronisation is sorted there are a couple more jobs to do.
The first is that we have to originate stuff. I am, for now, trying to just originate our own router LSA, which is a single, and relatively simple, LSA for us as a router. Even that is a pain as it has to update on any change to any links, even just designated router changing. We'll have to also originate a network LSA where we are the designated router for a subnet. That should not be a lot more complex.
Then we have to ensure we originate LSAs for external routing, e.g. connected networks like L2TP links, BGP routes, and so on, subject to various filtering logic. The current design makes it very easy for the OSPF subsystem to track any core routing changes, and effectively get events for adding, changing or removing external routing LSAs. Once again the issue of changes being too fast, and withdrawing routes, but that will have to be solved first.
So that is a milestone of maintaining LSAs that we originate.
Finally, after that, we have the simple job (!) of working out shortest path and injecting routes in to the core routing table. To be honest that is not too scary. We have a simple interface for injecting routes and removing them, which then ensures the routes propagate as needed (e.g. via BGP is required) and update the forwarding logic. There is a minor special case for equal path routing, but we have several systems for that in place already for bonding, so taking multiple OSPF targets an routing to them as a set is not a major change.
So, final milestone is working OSPF!
Once we have that we have a single area OSPF router and have loads of testing to do. Making it multi-area may come later, or may fall out of the database work anyway, not sure yet.
All good fun.
I am still working on the database exchange process. I almost have it working (well, far end thinks we have done the exchange, so a start).
It is messy, but getting there. Once I have the database exchange sorted, I have to sort the "flooding" logic. This will then mean we have, and maintain, the OSPF link state advertisement database.
There are a few gotchas that I can see. The way entries are withdrawn is, err, fun. You mark them as old (a hour) and ensure everyone has seen that, then remove it. That is not too bad, but it is a problem if you want to change your mind and now announce the entry again. You sort of have to wait for it to all be removed before re-creating it. You are supposed to cater for a 32 bit sequence wrapping as well, in a similar way. There is another related gotcha in that you are not allowed to update an LSA more often that a certain rate. Well, what if you have changes faster than that? You are meant to delay them. That sort of means storing a current version, and a "new version" in the database and a process to pick up that we want to move to a new version after a delay. That sort of crap is horrid - who makes a protocol like that? Just saying in the text of the RFC "delay" sounds so simple doesn't it - but delay means storage and timers and tasks.
I suspect that I will have to have a pending "new version" for any LSA we originate, and a task to pick up when to move to it. Arrrrg!
So, next milestone is full database synchronisation, not just exchange and loading, but flooding (as designated router, backup router and other router).
Once the database synchronisation is sorted there are a couple more jobs to do.
The first is that we have to originate stuff. I am, for now, trying to just originate our own router LSA, which is a single, and relatively simple, LSA for us as a router. Even that is a pain as it has to update on any change to any links, even just designated router changing. We'll have to also originate a network LSA where we are the designated router for a subnet. That should not be a lot more complex.
Then we have to ensure we originate LSAs for external routing, e.g. connected networks like L2TP links, BGP routes, and so on, subject to various filtering logic. The current design makes it very easy for the OSPF subsystem to track any core routing changes, and effectively get events for adding, changing or removing external routing LSAs. Once again the issue of changes being too fast, and withdrawing routes, but that will have to be solved first.
So that is a milestone of maintaining LSAs that we originate.
Finally, after that, we have the simple job (!) of working out shortest path and injecting routes in to the core routing table. To be honest that is not too scary. We have a simple interface for injecting routes and removing them, which then ensures the routes propagate as needed (e.g. via BGP is required) and update the forwarding logic. There is a minor special case for equal path routing, but we have several systems for that in place already for bonding, so taking multiple OSPF targets an routing to them as a set is not a major change.
So, final milestone is working OSPF!
Once we have that we have a single area OSPF router and have loads of testing to do. Making it multi-area may come later, or may fall out of the database work anyway, not sure yet.
All good fun.
2012-10-28
Junk calls
As anyone reading my blog for a while will know, I really hate junk calls.
Much like junk emails, I am sure that once upon a time they were sufficient few and far between that they were not a major problem. Junk post is sort of bearable because it is relatively low in volume - but imagine if every morning your post was a large sack, somewhere in which was the couple of "real" letters you needed. We all know email has become like that, and junk calls are getting as bad.
There are several ways to tackle junk callers...
When the office started getting literally hundreds of calls a day I automated a system to play one-sided conversations to keep the callers on as long as possible. I managed calls lasting 5 minutes, and some were posted on my blog. The particular company making such calls no longer call any of our numbers - it was very effective. Oddly a honey trap of thousands of other numbers did not get the same level of calls - and we wonder if the fact we had notified the TPS of our whole office number block was the reason we got the calls. Hard to prove though. If I get a chance I may test this theory by listing specific numbers with TPS and not listing others and checking levels of calls.
Of course the TPS should be the answer - tell them you don't want to be called. My experience is that it is not that helpful. I still get junk calls. When I mention the TPS they may apologise, etc, but usually hang up when I explain that they are criminals now.
This is a key point - such calls are criminally illegal if they are to numbers in the TPS. Its the law! It is also the law that you can make a civil claim for damages if you get such calls - so not just breach of law (and hence the only action would be taken by CPS or DPC), you can make a county court claim!
So cudos to this man:-
http://news.sky.com/story/1003497/victory-for-man-who-took-cold-caller-to-court
He told the junk caller that he would charge them. They still called. He charged them. He did not even rely on the legislation for junk calls for this - he relied on the making of a contractual offer (offering his time for a fee) which they accepted (by continuing to call).
The real shame is that it was not tested in court, but makes it well worth a try for anyone else similarly annoyed by them. Submitting a county court claim is quick and easy and relatively cheap. You can do it on-line.
The big problem I find is that you cannot find out who is behind the call. Well, you can, if you buy what they are selling, I suppose, but not just by asking. They typically have no clue who they are. They may know a brand name but can't say if a limited company or registered office address, etc. They are useless.
Much like junk emails, I am sure that once upon a time they were sufficient few and far between that they were not a major problem. Junk post is sort of bearable because it is relatively low in volume - but imagine if every morning your post was a large sack, somewhere in which was the couple of "real" letters you needed. We all know email has become like that, and junk calls are getting as bad.
There are several ways to tackle junk callers...
When the office started getting literally hundreds of calls a day I automated a system to play one-sided conversations to keep the callers on as long as possible. I managed calls lasting 5 minutes, and some were posted on my blog. The particular company making such calls no longer call any of our numbers - it was very effective. Oddly a honey trap of thousands of other numbers did not get the same level of calls - and we wonder if the fact we had notified the TPS of our whole office number block was the reason we got the calls. Hard to prove though. If I get a chance I may test this theory by listing specific numbers with TPS and not listing others and checking levels of calls.
Of course the TPS should be the answer - tell them you don't want to be called. My experience is that it is not that helpful. I still get junk calls. When I mention the TPS they may apologise, etc, but usually hang up when I explain that they are criminals now.
This is a key point - such calls are criminally illegal if they are to numbers in the TPS. Its the law! It is also the law that you can make a civil claim for damages if you get such calls - so not just breach of law (and hence the only action would be taken by CPS or DPC), you can make a county court claim!
So cudos to this man:-
http://news.sky.com/story/1003497/victory-for-man-who-took-cold-caller-to-court
He told the junk caller that he would charge them. They still called. He charged them. He did not even rely on the legislation for junk calls for this - he relied on the making of a contractual offer (offering his time for a fee) which they accepted (by continuing to call).
The real shame is that it was not tested in court, but makes it well worth a try for anyone else similarly annoyed by them. Submitting a county court claim is quick and easy and relatively cheap. You can do it on-line.
The big problem I find is that you cannot find out who is behind the call. Well, you can, if you buy what they are selling, I suppose, but not just by asking. They typically have no clue who they are. They may know a brand name but can't say if a limited company or registered office address, etc. They are useless.
2012-10-25
Most complete?
You can tell I have been sat here all afternoon with a cup of soup and paracetamol watching daytime TV. Ug... But I note that BT sell what they claim is the "most complete broadband package"...
I always try and pick adverts apart at the best of times, but I am not sure what "most complete" means, or what it means to have a "complete broadband package".
We can probably put to one side the fact that "broadband" is a technical term that relates to the multiple frequency bands / carriers used on DSL lines (ADSL and VSDL). It has started to become a term for "Internet access", annoyingly.
But to my view, even "Internet access" simply means the ability to send and receive IP packets. In order to make the package "complete" I would say you want caching DNS resolvers. But you have a "complete" internet access package if you can send and receive IP packets. Everything else is extra.
If you want a TV package, that is part of a TV package, not a broadband package. A "broadband package" is "complete" if (calling it an "internet access package") it provides internet access. How can it be "more complete" or "most complete"?
Obviously, to be even vaguely "complete" as an "internet access package" you have to include the current IP protocol, IPv6. Does it I wonder? If another ISP also allows IPv4 packets, and DNS, and so on, but also IPv6, does that ISP not have a more complete broadband package that BT? If that is the case, then BT's package is not the "most complete" is it?
Hmm. Who is it that one complains to about adverts these days?
I always try and pick adverts apart at the best of times, but I am not sure what "most complete" means, or what it means to have a "complete broadband package".
We can probably put to one side the fact that "broadband" is a technical term that relates to the multiple frequency bands / carriers used on DSL lines (ADSL and VSDL). It has started to become a term for "Internet access", annoyingly.
But to my view, even "Internet access" simply means the ability to send and receive IP packets. In order to make the package "complete" I would say you want caching DNS resolvers. But you have a "complete" internet access package if you can send and receive IP packets. Everything else is extra.
If you want a TV package, that is part of a TV package, not a broadband package. A "broadband package" is "complete" if (calling it an "internet access package") it provides internet access. How can it be "more complete" or "most complete"?
Obviously, to be even vaguely "complete" as an "internet access package" you have to include the current IP protocol, IPv6. Does it I wonder? If another ISP also allows IPv4 packets, and DNS, and so on, but also IPv6, does that ISP not have a more complete broadband package that BT? If that is the case, then BT's package is not the "most complete" is it?
Hmm. Who is it that one complains to about adverts these days?
Taking a stand?
This one is aimed at other ISPs using BT services.
All of you spend a lot of time on disputes, I am sure, not just SFI charges but mistakes, though I suspect SFI charges are the main one. It is very time consuming.
So, we are taking a stand (what a surprise).
We have told them that we will check the bill and advise them of errors (i.e. what the error is and why), but only the once. We will then withhold the payment of the disputed charges, as per the contract. We believe that this is all we have to do as per the contract.
When they come back later asking why the invoice was under paid (even though we told them), we will only reply if they agree to pay a consultancy fee, probably £75/hour or part.
We might reply confirming once again our offer of consultancy to help them identify their mistakes, and that the withheld amount is "as per previously advised disputes" but no more work than that.
We might even make an automated reply stating that, and stating an alternative email address for "purchase of consultancy services" specifically. If they email that, we help them our and invoice for our time.
To be quite frank I am sick and tired of having staff spend hours and hours fixing BT errors on their bill. They should have no errors. It is simply not acceptable.
Any other ISPs got similar approaches? Please do post a follow up...
P.S. Examples :-
I just looked at a small batch of SFI charge disputes BT resolved, 9 of them, totalling £1,500. They are all cases of an SFI or SFI2 charge often with extra modules, disputed because BT did in fact find and fix a fault on the network, so should have been free. Simple disputes, usually quoting the BT engineer notes back at BT.
With no explanation BT have chosen to only partly credit 4 of then, fully crediting the remaining 5. This means we still have £214 in dispute.
So, we now have another round of "why is this invoice under paid" where we have to explain the dispute again, and that they only partly credited us, and that the balance remains in dispute.
Just an example of the total stupidity here - one of the disputes resolved this month dates back to last December. The charge was the standard cost for an SFI, £144.00. The credit we have received is £137.80, so £6.20 still in dispute. Why do that? How do they do that? It makes no sense at all - but it means more work for us in handling the disputes.
Update: Apparently this has got as far as Ian Livingstone!
All of you spend a lot of time on disputes, I am sure, not just SFI charges but mistakes, though I suspect SFI charges are the main one. It is very time consuming.
So, we are taking a stand (what a surprise).
We have told them that we will check the bill and advise them of errors (i.e. what the error is and why), but only the once. We will then withhold the payment of the disputed charges, as per the contract. We believe that this is all we have to do as per the contract.
When they come back later asking why the invoice was under paid (even though we told them), we will only reply if they agree to pay a consultancy fee, probably £75/hour or part.
We might reply confirming once again our offer of consultancy to help them identify their mistakes, and that the withheld amount is "as per previously advised disputes" but no more work than that.
We might even make an automated reply stating that, and stating an alternative email address for "purchase of consultancy services" specifically. If they email that, we help them our and invoice for our time.
To be quite frank I am sick and tired of having staff spend hours and hours fixing BT errors on their bill. They should have no errors. It is simply not acceptable.
Any other ISPs got similar approaches? Please do post a follow up...
P.S. Examples :-
I just looked at a small batch of SFI charge disputes BT resolved, 9 of them, totalling £1,500. They are all cases of an SFI or SFI2 charge often with extra modules, disputed because BT did in fact find and fix a fault on the network, so should have been free. Simple disputes, usually quoting the BT engineer notes back at BT.
With no explanation BT have chosen to only partly credit 4 of then, fully crediting the remaining 5. This means we still have £214 in dispute.
So, we now have another round of "why is this invoice under paid" where we have to explain the dispute again, and that they only partly credited us, and that the balance remains in dispute.
Just an example of the total stupidity here - one of the disputes resolved this month dates back to last December. The charge was the standard cost for an SFI, £144.00. The credit we have received is £137.80, so £6.20 still in dispute. Why do that? How do they do that? It makes no sense at all - but it means more work for us in handling the disputes.
Update: Apparently this has got as far as Ian Livingstone!
Have you paid us yet?
Just as in social interactions, there are, in business, some things that are bad form, even taboo. They create bad will and causes disproportionate annoyance. One of these taboos is chasing people to pay a bill before the due date. Obviously people can pay before the due date, but most people do not for simple business reasons.
It is a tricky one. As a supplier we have a few people who will not quite pay on time, or need some sort of nudge to convince them to pay on time, and it is very tempting to chase them in advance of being late - i.e. before the due date. When you do that people get quite annoyed - "Of course we will be paying on time". The annoyance is usually because chasing the payment in advance is seen as untrusting and suggesting the customer will pay late. I can't guarantee that our accounts dept have done this, but it is something we try not to do, and would normally only be someone that we really do not trust to pay on time based on a long history of such. Even so, we would have to expect that sort of reaction.
We don't usually have much of a problem because we do charge the statutory late payment penalties that apply when a business customer pays us late. We usually credit the first time, but this is a fully automated process. People learn that at the very least, if they pay late, they get the hassle (trying to get a late payment credited, etc). So they pay on time, or change to direct debit (and so pay on time). It works well.
One trick we did was send a statement mid month if a payment is due. Not a chasing letter or a call, just a statement, what invoices there are and when due and how much. That seems not to cause annoyance, thankfully. It also helps sort any cases where someone has, for some reason, not seen an invoice.
But as a customer, we pay suppliers on time. We are very careful to pay people on time, even the likes of BT where the payment is a very large amount. We plan cash flow carefully to make sure we never pay late. If ever, by mistake, we pay late, we offer to pay the statutory late payment penalties even if the supplier did not know about them. It would be somewhat hypercritical if we did anything different.
Our friends at BT have, however, started getting a tad annoying of late. Some of the BT accounts are complicated because every single month there are a long list of disputes, and also a list of credits where they have agreed previous disputes and deductions are in fact valid. We advise BT clearly of what we dispute and pay the balance on the due date, not a day later. Some of the BT accounts are not a problem, and paid on time, every month, the full amount.
What has got annoying is BT chasing us asking have we paid an invoice, before it is due. This is when the invoice is not due for a week. We always pay on time, but they still ask, every damn month, on several of the BT accounts. And it is starting to wind me up now!
So, am I right? Is it a taboo to chase people for payment before it is due? It is fair that this annoys me?
FYI we asked BT why, and they said that they need to know when we will pay for their forecasts (cash flow, I assume). As the contract does not require us to provide this, I have told them an hourly rate for any future queries of this nature - we'll see what happens.
Of course, to add to the fun, BT have a odd idea on when payment is due. We have 28 days terms, so an invoice issued on 1st is due on 29th. Oddly they state "due on" not "to arrive by" as we would, but when they chase us for payment like this they say that they are expecting payment by 28th. Thankfully the invoice does not say "28 days" but actually states "due on 29th" so not ambiguous at all, but it does just add to the annoyance.
Ironically, whilst it is normal for 28 days from 1st to be 29th, (1+28=29), when we issue invoices we base payment terms on time as well as date, so an invoice issued 09:00:00 on 1st would be due by 09:00:00 on 29th, if on 28 calendar days terms. However, an invoice issued 00:00:00 on 1st (as most are) would be due on or before 23:59:59 on 28th (and we state the date and time clearly). In practice you have to be more than a day late to get penalties, so that is academic, but amused me how something as simple as this can have ambiguities :-)
2012-10-23
Slow SFP
Well, been off most of today with a rotten cold - why me?
Made very slow progress on OSPF as a result. I do, however, have a nice packet dump of two linux boxes running bird talking OSPF to check my understanding for the next stage.
For now I may just play some 3D WoW and go to bed... Must get ahead of Mikey.
Made very slow progress on OSPF as a result. I do, however, have a nice packet dump of two linux boxes running bird talking OSPF to check my understanding for the next stage.
For now I may just play some 3D WoW and go to bed... Must get ahead of Mikey.
IPv6 privacy addressing
With IPv4, a machine would have its own IP address on a subnet, and that would be it. Yes, it is true that each interface a device had would be on a separate subnet and so a separate address. It is also true that a device might have several distinct subnets even on the same interface. But these were exceptions to the normal simple subnet configuration.
IPv6 has slight different ways of working. It is normal for an interface to have multiple IPv6 addresses, and there are different scopes of address. For example, each interface has an link local address (starting FE80:) which the device creates for itself (typically based on MAC address) and does not need to be allocated by some system. It is useful, in principle, that a device always has some unique address with which to communicate on the interface itself, though it does cause some confusion.
An interface will also have one or more permanent addresses, either hard coded or allocated by some automated means (SLAAC/DHCPv6). This is also often based on the MAC address and the prefix that applies to the interface.
However, there is also the notion that an interface has one or more temporary addresses. This can, in theory, be allocated by DHCPv6, or more likely made up randomly by the device (checking it is not a duplicate). This is an address in the prefix for the interface, but not one based on the device MAC. These are usually called privacy addresses as their purpose is to avoid exposing details of your network to the world. Using only fixed permanent addresses it becomes obvious to the outside world how many machines you have, and allows traffic to those addresses later (if you did not have a firewall!). It allows the same machine seen twice to be recognised as the same machine, just like cookies and many other systems do already and continue to do with IPv6. With IPv4 the use of NAT would hide the internet network from the world, a bit. We don't want NAT for IPv6.
If someone is using a computer from home like they used to with IPv4 and NAT, then giving the same features they had before, no matter how pointless, is not that daft. Hence the use of privacy addressing. Normally a privacy address has a short life, and a new temporary address is created. Many of these can overlap, with existing TCP sessions carrying on using the old address, and new sessions using thew new one. Eventually old addresses can be removed when no longer in use. This is fine if all you do is use you home computer to access facebook and gmail.
However, as a business, we use computers for business. We have systems that log accesses using IP address and reverse DNS. We have systems that include IP address in login session tracking over multiple web pages. We have access control systems that use IP address and reverse DNS before even allowing a login. We have firewalls that use IP address. This is just the same as using proper IPv4. IPv6 makes life a lot easier as the whole company can be within on /48 rather than many fragmented IPv4 blocks, but otherwise the principle is the same.
The problem is that more and more machines are now operating privacy addressing by default. This includes linux, windows, mac, and iPad and iPhone. With many of these there is a way to turn it off, but not with all. If you do have any systems that even just log IP addresses, then privacy addresses are a pain.
So, what is the solution? The best solution is for devices to allow you to turn it off if you need. If devices used DHPv6 to get the address then the administrator could set a DHCPv6 server to give fixed "temporary" addresses and avoid that. However, it seems there are many devices now that do not get a temporary address by DHCPv6, have privacy addressing on by default, and do not allow you to turn it off.
Sadly I can think of a good solution, and it sort of involves NAT on IPv6. Yes, that would be horrid. NAT is evil. Well, this idea is only half evil, honest. The idea is that we know the permanent address that a device has based on its MAC - that does indeed seem to be very consistent and standard. So we can spot, at the border router/firewall (AKA FireBrick) where a device on the LAN is using a privacy address. So, we can, err, map it to the address it should be using!
This is not quite as evil as normal NAT. For a start there is no port change involved as there is no address sharing. Also, the address to which the session is mapped is an address that should work for the device sending the traffic as it will be its normal permanent address. This means, in theory, that even embedded addresses in protocols for return connections should work unless some very specific binding is used by the application.
It would also be possible to only do this mapping where contacting specific machines, e.g. the rest of the office network, and not when accessing the Internet in general, hence controlling where privacy addressing is used and where it is not.
So, I am seriously considering this as a standard feature in FireBricks, at the subnet level (like the nat setting) for all traffic from the subnet, and in the firewalling rules (like the set-nat setting) allowing finer control of when it is applied and not.
Have I really turned to the dark side? Should I do this?
IPv6 has slight different ways of working. It is normal for an interface to have multiple IPv6 addresses, and there are different scopes of address. For example, each interface has an link local address (starting FE80:) which the device creates for itself (typically based on MAC address) and does not need to be allocated by some system. It is useful, in principle, that a device always has some unique address with which to communicate on the interface itself, though it does cause some confusion.
An interface will also have one or more permanent addresses, either hard coded or allocated by some automated means (SLAAC/DHCPv6). This is also often based on the MAC address and the prefix that applies to the interface.
However, there is also the notion that an interface has one or more temporary addresses. This can, in theory, be allocated by DHCPv6, or more likely made up randomly by the device (checking it is not a duplicate). This is an address in the prefix for the interface, but not one based on the device MAC. These are usually called privacy addresses as their purpose is to avoid exposing details of your network to the world. Using only fixed permanent addresses it becomes obvious to the outside world how many machines you have, and allows traffic to those addresses later (if you did not have a firewall!). It allows the same machine seen twice to be recognised as the same machine, just like cookies and many other systems do already and continue to do with IPv6. With IPv4 the use of NAT would hide the internet network from the world, a bit. We don't want NAT for IPv6.
If someone is using a computer from home like they used to with IPv4 and NAT, then giving the same features they had before, no matter how pointless, is not that daft. Hence the use of privacy addressing. Normally a privacy address has a short life, and a new temporary address is created. Many of these can overlap, with existing TCP sessions carrying on using the old address, and new sessions using thew new one. Eventually old addresses can be removed when no longer in use. This is fine if all you do is use you home computer to access facebook and gmail.
However, as a business, we use computers for business. We have systems that log accesses using IP address and reverse DNS. We have systems that include IP address in login session tracking over multiple web pages. We have access control systems that use IP address and reverse DNS before even allowing a login. We have firewalls that use IP address. This is just the same as using proper IPv4. IPv6 makes life a lot easier as the whole company can be within on /48 rather than many fragmented IPv4 blocks, but otherwise the principle is the same.
The problem is that more and more machines are now operating privacy addressing by default. This includes linux, windows, mac, and iPad and iPhone. With many of these there is a way to turn it off, but not with all. If you do have any systems that even just log IP addresses, then privacy addresses are a pain.
So, what is the solution? The best solution is for devices to allow you to turn it off if you need. If devices used DHPv6 to get the address then the administrator could set a DHCPv6 server to give fixed "temporary" addresses and avoid that. However, it seems there are many devices now that do not get a temporary address by DHCPv6, have privacy addressing on by default, and do not allow you to turn it off.
Sadly I can think of a good solution, and it sort of involves NAT on IPv6. Yes, that would be horrid. NAT is evil. Well, this idea is only half evil, honest. The idea is that we know the permanent address that a device has based on its MAC - that does indeed seem to be very consistent and standard. So we can spot, at the border router/firewall (AKA FireBrick) where a device on the LAN is using a privacy address. So, we can, err, map it to the address it should be using!
This is not quite as evil as normal NAT. For a start there is no port change involved as there is no address sharing. Also, the address to which the session is mapped is an address that should work for the device sending the traffic as it will be its normal permanent address. This means, in theory, that even embedded addresses in protocols for return connections should work unless some very specific binding is used by the application.
It would also be possible to only do this mapping where contacting specific machines, e.g. the rest of the office network, and not when accessing the Internet in general, hence controlling where privacy addressing is used and where it is not.
So, I am seriously considering this as a standard feature in FireBricks, at the subnet level (like the nat setting) for all traffic from the subnet, and in the firewalling rules (like the set-nat setting) allowing finer control of when it is applied and not.
Have I really turned to the dark side? Should I do this?
2012-10-20
Tested!
Got the kit back from where my daughter is living, and clearly, at some point, they have had someone come in and do electrical safety on everything. It was all covered in stickers, which all look like this:-
Odd? Don't they have state the re-test date or something normally? After all, the whole point of the sticker is, as I understand it, to show testing has been done, and when a re-test is needed.
Ah, but hang on - here it is under a flap:-
So what's that flap for? Oh! it is removable:-
And sticky:-
And leaves nice sealed glossy finish that you can't alter:-
Odd? Don't they have state the re-test date or something normally? After all, the whole point of the sticker is, as I understand it, to show testing has been done, and when a re-test is needed.
Ah, but hang on - here it is under a flap:-
So what's that flap for? Oh! it is removable:-
And sticky:-
And leaves nice sealed glossy finish that you can't alter:-
And the whole thing seems to be tamper evident:-
They are probably expensive stickers. Why go to all that effort to copy serial number on to them, and then not peal off the backing and stick it down?
I can only hope that the whoever it was knew more about working the test equipment than the stickers!
When is a fault not a fault?
When it is too costly for BT to fix, maybe?
Having a fun one with BT (well, "fun" is not the word) where an unfortunate customer has lost just over 25% of the 63Mb/s speed they had on FTTC when their neighbour also got FTTC.
It is right on the borderline, but (we think) the wrong side (for BT) in that it did drop just more than 25%. Not many people realise that an FTTC line should not drop by 25% over a 14 day period. It is there in the handbook, but even BT do not seem to understand this. All they seem to care about is that the availability checker shows the estimated speed which matches what the line gets (well, it does now, as it seems that they changed the checker!).
BT seem totally happy to ignore their own rules if they are not convenient. What is worse is they know the cause of the problem (a short length of Aluminium cable) and the fix (to replace it with Copper), but that is not something they want to do - even though they are the ones that made this 25% drop rule.
We'll see how it goes - if they actually agree it has dropped more than 25% but still refuse to fix the fault, then this will be more of a story. I'll post more when we get to the bottom of it.
From our point of view we don't guarantee any speed, so whilst we are not in breach of contract with our customer, and we charge the same for 46M as we do for 63M, it is not exactly very nice on the customer to lose the speed like this. As a result we are doing everything possible to try and force BT to follow their own rules and fix the problem.
Update: Unfortunately, analysis of the sync rates and changes suggests that for this customer the sync rate dropped just too slowly. i.e. more than 25% overall, but over more slightly than 14 days. The rate drop within 14 days being just below 25%. Asa result BT have refused to take any action to restore the previous speeds. In the long term vectoring may provide a means to reduce the crosstalk affecting this customer, but this could be some time off.
Having a fun one with BT (well, "fun" is not the word) where an unfortunate customer has lost just over 25% of the 63Mb/s speed they had on FTTC when their neighbour also got FTTC.
It is right on the borderline, but (we think) the wrong side (for BT) in that it did drop just more than 25%. Not many people realise that an FTTC line should not drop by 25% over a 14 day period. It is there in the handbook, but even BT do not seem to understand this. All they seem to care about is that the availability checker shows the estimated speed which matches what the line gets (well, it does now, as it seems that they changed the checker!).
BT seem totally happy to ignore their own rules if they are not convenient. What is worse is they know the cause of the problem (a short length of Aluminium cable) and the fix (to replace it with Copper), but that is not something they want to do - even though they are the ones that made this 25% drop rule.
We'll see how it goes - if they actually agree it has dropped more than 25% but still refuse to fix the fault, then this will be more of a story. I'll post more when we get to the bottom of it.
From our point of view we don't guarantee any speed, so whilst we are not in breach of contract with our customer, and we charge the same for 46M as we do for 63M, it is not exactly very nice on the customer to lose the speed like this. As a result we are doing everything possible to try and force BT to follow their own rules and fix the problem.
Update: Unfortunately, analysis of the sync rates and changes suggests that for this customer the sync rate dropped just too slowly. i.e. more than 25% overall, but over more slightly than 14 days. The rate drop within 14 days being just below 25%. Asa result BT have refused to take any action to restore the previous speeds. In the long term vectoring may provide a means to reduce the crosstalk affecting this customer, but this could be some time off.
Divide and conquer
This blog is read by a wide range of people, both technical and non technical. The problem is that some of the posts are totally meaningless to some of the people reading my blog. Obviously Pauline, who is now master of iPhone settings, has no problem understanding my latest post on OSPF, but for anyone else, here is a bit more of an explanation of what the hell I was talking about...
The post was about OSPF (which stands for Open Shortest Path First). You probably don't want to really know all of the details. In practice it is a protocol. This is much like you might expect in normal English. In life there is protocol for formal events, or how one talks to the Queen, or anything where there is some communications. It is all about everyone pre-agreeing the way things are done, so there is no misunderstanding. The same is true for computers, but typically in a lot more detail. OSPF is such a protocol - it is a set of rules for how computers talk to each other in a specific set of circumstances. In this case the protocol itself is about routing which is itself a process for how computers communicate with each other. So it is a communications protocol about how computers agree on how they will communicate information in future (confused yet?).
In order to make something (a computer, but in this case it is the FireBrick) handle this protocol, we have to write software. This is kind of what I do. I have written software since I was in secondary school. Software is simply a set of instructions, much like a cooking recipe tells you the steps to make a cake, the software tells the computer how to do something, in this case how to handle this particular protocol. Software is a tad different to a cooking recipe in that the steps that the computer follows are very detailed, and there are a lot of them. Software can be hugely complex.
The problem is that software can be so big and complex that you can't just start at the beginning and write it. It is not like reading a book. You have to work out the overall plan, the architecture. Like making a complicated building.
So, in order to write the OSPF software I have divided the problem up in to several distinct steps. I described three steps in the OSPF post. This is making the larger problem smaller. Each smaller step is easier to write, and, importantly, to test works before moving on to the next step. Completing each step you can see how far you have got, and have some sense of achievement.
This can be done at different levels. For example, my first step, as I explained, is the "hello protocol". This is one small part of the way OSPF works. As the name suggests it is how the computers "say hello" to each other. Having done that they can go on to say more interesting things. But even this first step can then be broken down in to smaller steps. You have the saying hello, and the bit where other computers say hello to you. Both of these have steps, e.g. where you construct the actual message itself with all its parts, and send the message in a way that the neighbouring computers will be able to get it. There are various parts to the messages, including authentication (which is like showing your ID card to other computers so they know you are who you say you are). So each step in the process can be broken down in to smaller steps.
This divide and conquer approach is a sensible way to tackle any large problem, and is quite important when writing software for computers.
There are other tricks of the trade. It is not always about taking a large problem and reducing to smaller steps. Some times I also work out the tools I need - the building bricks that are at the bottom. This is like building some foundations you know you will need even before you have worked out these top level steps. So some times the software is built from the top down and from the ground up and meets in the middle. This usually works well from lots of experience - knowing right away what these building bricks will be, making it easier to then divide the problem up in a way to use the tools you have constructed.
Hopefully the helps explain a bit more of what the OSPF posts are actually about, even if you do not understand all of the details.
The post was about OSPF (which stands for Open Shortest Path First). You probably don't want to really know all of the details. In practice it is a protocol. This is much like you might expect in normal English. In life there is protocol for formal events, or how one talks to the Queen, or anything where there is some communications. It is all about everyone pre-agreeing the way things are done, so there is no misunderstanding. The same is true for computers, but typically in a lot more detail. OSPF is such a protocol - it is a set of rules for how computers talk to each other in a specific set of circumstances. In this case the protocol itself is about routing which is itself a process for how computers communicate with each other. So it is a communications protocol about how computers agree on how they will communicate information in future (confused yet?).
In order to make something (a computer, but in this case it is the FireBrick) handle this protocol, we have to write software. This is kind of what I do. I have written software since I was in secondary school. Software is simply a set of instructions, much like a cooking recipe tells you the steps to make a cake, the software tells the computer how to do something, in this case how to handle this particular protocol. Software is a tad different to a cooking recipe in that the steps that the computer follows are very detailed, and there are a lot of them. Software can be hugely complex.
The problem is that software can be so big and complex that you can't just start at the beginning and write it. It is not like reading a book. You have to work out the overall plan, the architecture. Like making a complicated building.
So, in order to write the OSPF software I have divided the problem up in to several distinct steps. I described three steps in the OSPF post. This is making the larger problem smaller. Each smaller step is easier to write, and, importantly, to test works before moving on to the next step. Completing each step you can see how far you have got, and have some sense of achievement.
This can be done at different levels. For example, my first step, as I explained, is the "hello protocol". This is one small part of the way OSPF works. As the name suggests it is how the computers "say hello" to each other. Having done that they can go on to say more interesting things. But even this first step can then be broken down in to smaller steps. You have the saying hello, and the bit where other computers say hello to you. Both of these have steps, e.g. where you construct the actual message itself with all its parts, and send the message in a way that the neighbouring computers will be able to get it. There are various parts to the messages, including authentication (which is like showing your ID card to other computers so they know you are who you say you are). So each step in the process can be broken down in to smaller steps.
This divide and conquer approach is a sensible way to tackle any large problem, and is quite important when writing software for computers.
There are other tricks of the trade. It is not always about taking a large problem and reducing to smaller steps. Some times I also work out the tools I need - the building bricks that are at the bottom. This is like building some foundations you know you will need even before you have worked out these top level steps. So some times the software is built from the top down and from the ground up and meets in the middle. This usually works well from lots of experience - knowing right away what these building bricks will be, making it easier to then divide the problem up in a way to use the tools you have constructed.
Hopefully the helps explain a bit more of what the OSPF posts are actually about, even if you do not understand all of the details.
Returning to OSPF
Now that the IPEXPO is over, I can get back to work, and to OSPF. It seems (from discussions at the EXPO) that people would indeed just expect OSPF to be in a router. This is what we expected, to be honest. We have sold boxes to people at the lower end (SME) where OSPF is not needed or expected. We have also sold boxes at the higher end to ISPs where BGP will usually work just as well for the purpose (announcing connected L2TP routes in to the network).
In A&A we just use BGP and OSPF was not actually necessary. It is clearly nice to have though and other ISPs that have used the FireBricks for some years now, using BGP, have expressed a preference for OSPF because that is how they normally work, which is fair enough.
I have broken the development down in to three key steps:-
1. Hello: The hello protocol is used to find neighbouring routers on the network connection (subnet or interface) and establish which routers are the designated router and backup router. We have this stage working now, and it is more than it sounds as it includes all of the packet header processing and generation and authentication both ways.
2. Database exchange and update: This is where the router communicates the current database of link state attributes, and then continues to update the database as changes happen. Each OSPF router has the same database of LSA records. It may originate some of these records itself, and the rest of the records are from other OSPF routers. Some of the records it originates are as a result of the protocol itself (i.e. a designated router originates the subnet on which it exists) and some may be from the routing table such as connected L2TP session routes that the router has internally. It communicates the records to its neighbours to ensure every router is up to date with the same set of LSAs. Making this work is what I have to work on next. There is a lot of detail in the RFCs on this process, and it will be a bit of a slog to get through, and especially to test.
3. The LSAs result in a database that contains topology details as well as other (external) routes. The topology describes how all of the OSPF routers are currently interconnected, and also the logical cost of each link. Using this it is possible to make a tree starting from yourself and working out the shortest path (by cost) to every other node in the network. From this tree one can make routing entries that are the routes that the LSA database describes. For each of these routes the shortest path next hop can be used to actually install and update routes in the routing table.
I did have to make an architectural decision here. Basically, the LSA database could have been directly incorporated in to my existing routing structures, like BGP routes are now. This routing structure already works out best routes based on logic defined in BGP and could be extended to understand the OSPF rules and link in to the shortest path logic.
However, the decision I have made is to work in much the same way as other OSPF implementations - where the LSA database is separate and part of the OSPF function. This makes slightly more sense as the LSA database is different in structure and content to the existing routing. The normal routing works on a record relating to a prefix, and within that an ordered set of possible routes with the best at the top. Updates relate to the prefix itself, and ensuring the prefix best route is updated to neighbours and the forwarding table. For OSPF the LSA records can all independently need updating regardless of whether they happen to be the best route for a prefix, so a simple list of all of the LSA records is more logical. It also has to periodically send updates to routes to enure they do not time out, and handle individual LSAs timing out or being withdrawn independently to the prefix itself or its choice of best route.
By separating the LSA database it also makes the coding stages distinct. I can do step 2, to maintain the LSA database and communicate it with neighbours, totally independently to step 3 where we pick the shortest path and update live routing. The existing code allows me to track routing updates from other sources (e.g. L2TP) and feed changes in to the LSA database as records we originate. It obviously allows OSPF to inject and maintain the routes that step 3 creates back in to the live routing tables. These interactions with the core routing can be logged and debugged carefully and even simulated to test OSPF code without upsetting the rest of the system.
So, the plan is to work on step 2 and step 3 next week. Once I have OSPF working in some sensible way it will be added to alpha releases to allow testing and comments from customers. I am still somewhat busy, but getting OSPF working is quite high on my list. Anyone wanting to try the OSPF code should get on the testers mailing list (see lists.firebrick.co.uk).
In A&A we just use BGP and OSPF was not actually necessary. It is clearly nice to have though and other ISPs that have used the FireBricks for some years now, using BGP, have expressed a preference for OSPF because that is how they normally work, which is fair enough.
I have broken the development down in to three key steps:-
1. Hello: The hello protocol is used to find neighbouring routers on the network connection (subnet or interface) and establish which routers are the designated router and backup router. We have this stage working now, and it is more than it sounds as it includes all of the packet header processing and generation and authentication both ways.
2. Database exchange and update: This is where the router communicates the current database of link state attributes, and then continues to update the database as changes happen. Each OSPF router has the same database of LSA records. It may originate some of these records itself, and the rest of the records are from other OSPF routers. Some of the records it originates are as a result of the protocol itself (i.e. a designated router originates the subnet on which it exists) and some may be from the routing table such as connected L2TP session routes that the router has internally. It communicates the records to its neighbours to ensure every router is up to date with the same set of LSAs. Making this work is what I have to work on next. There is a lot of detail in the RFCs on this process, and it will be a bit of a slog to get through, and especially to test.
3. The LSAs result in a database that contains topology details as well as other (external) routes. The topology describes how all of the OSPF routers are currently interconnected, and also the logical cost of each link. Using this it is possible to make a tree starting from yourself and working out the shortest path (by cost) to every other node in the network. From this tree one can make routing entries that are the routes that the LSA database describes. For each of these routes the shortest path next hop can be used to actually install and update routes in the routing table.
I did have to make an architectural decision here. Basically, the LSA database could have been directly incorporated in to my existing routing structures, like BGP routes are now. This routing structure already works out best routes based on logic defined in BGP and could be extended to understand the OSPF rules and link in to the shortest path logic.
However, the decision I have made is to work in much the same way as other OSPF implementations - where the LSA database is separate and part of the OSPF function. This makes slightly more sense as the LSA database is different in structure and content to the existing routing. The normal routing works on a record relating to a prefix, and within that an ordered set of possible routes with the best at the top. Updates relate to the prefix itself, and ensuring the prefix best route is updated to neighbours and the forwarding table. For OSPF the LSA records can all independently need updating regardless of whether they happen to be the best route for a prefix, so a simple list of all of the LSA records is more logical. It also has to periodically send updates to routes to enure they do not time out, and handle individual LSAs timing out or being withdrawn independently to the prefix itself or its choice of best route.
By separating the LSA database it also makes the coding stages distinct. I can do step 2, to maintain the LSA database and communicate it with neighbours, totally independently to step 3 where we pick the shortest path and update live routing. The existing code allows me to track routing updates from other sources (e.g. L2TP) and feed changes in to the LSA database as records we originate. It obviously allows OSPF to inject and maintain the routes that step 3 creates back in to the live routing tables. These interactions with the core routing can be logged and debugged carefully and even simulated to test OSPF code without upsetting the rest of the system.
So, the plan is to work on step 2 and step 3 next week. Once I have OSPF working in some sensible way it will be added to alpha releases to allow testing and comments from customers. I am still somewhat busy, but getting OSPF working is quite high on my list. Anyone wanting to try the OSPF code should get on the testers mailing list (see lists.firebrick.co.uk).
2012-10-19
That is not how it works - or is it?
That is not how GPS works. GPS receivers get signals from satellites, several of them, and use these to work out where they are. Any signalling of the location of the bar will not involve the bar or GPS signalling device sending a signal in to space. There is no chance that a small GPS tracking device in a chocolate bar will be doing that. At best it will signal using mobile data.
Now, there are adverts where what they state is clearly fiction, which is fine. The problem with adverts like this is that they are not obviously fiction, they are stating something that just re-enforces peoples misunderstandings. Why do that? Does it make the offer sound even better somehow? Do we not have rules against lies in adverts? It is annoying.
If I find one, I may have to take a holiday somewhere with no mobile signal, and then activate it, so see if they meet the 24 hour time they put in their T&Cs. After all, if the advert were true, that would not matter, would it?
Update:
I may be wrong! It is true that (a) GPS trackers normally work as I have described above: with a GPS receiver and a mobile data module, and (b) that there is an annoying common misconception that GPS receivers somehow send a signal in to space. However, they may have been extra clever here in making an advert that annoys people like me, that are fed up explaining this to people - if so, I am impressed, and my blog post has helped spread their advert as they intended, well done!
As some people have pointed out to me - there are in fact some devices that do signal to a satellite. Suddenly it makes sense, as these things are intended as SOS devices for people that go mountaineering and the like so they can get help wherever they are. What also makes sense is the helicopters, as that is exactly what these services would do to rescue such a person. It sounds like maybe they are using such a service, perhaps to show off the service itself in a followup advert when someone has won. Even so, I will be surprised if somehow they fit such a device in a chocolate bar!
Re-reading the wording, it is interesting for the cynical. Normally the advert is worded such that you are now buying something that has a chance of winning a prize - like a lottery scratch card. However, it starts "In the very near future, someone, somewhere, will purchase a chocolate bar. The bar will be equipped with a GPS signalling device...". They are not actually saying there are in fact such bars now are they, just that "In the very near future...". So maybe they have not released them just yet.
I also seriously doubt a satellite signalling device would fit in the weight of an Aero bar, let alone the size, thereby making it very easy to find without opening the bar.
IPEXPO 2012 FireBrick
 |
| Who let the dogs out? |
(yes, "Earls Court 2" which is by "Earl's Court" tube station, arrrg!)
It was busy! Well done to everyone that helped from A&A and Watchfront, on the stand and in the months leading up to this. We have not done a show before like this, but we think we got it right.
I did not get a chance to look around myself much, but from what I did see there was quite an interesting mix. Some stands were just a TV with slide show, and some merchandise (pens, juggling balls) and a couple of people. Some stands had their kit on the stand, and some (like ours) were actually demonstrating the equipment working. Other exhibitors said we were a busy stand!
Taking the orc was a real winner - we'll definitely do that again - nobody had anything like that. There were some bees, some things that looked like M&Ms, some dogs, a fairy, some butlers, some doctors, all sorts, but no other orcs. Thrall really got people on to the stand and we printed pictures on the spot. We used a cable rather than wifi, which was probably the best choice given the vast number of APs in use (even though they were meant to be banned). Printing from the camera does take around a minute, on a high quality canon photo printer, but that gave us a chance to explain what FireBricks are. Even other exhibitors (see above) had pictures taken. We uploaded the images directly from the camera as it printed and stuck a URL on the back so people could get it on their phones and facebook it.
We gave out FireBrick pint glasses, and they went down very well indeed. We gave out thousands of FireBrick chocolates, and lots of leaflets. I personally think the pint glasses were the best swag at the show, but I am biased.
Thanks to everyone that came along - several readers of my blog, as well as many A&A, WF, and FireBrick customers, but also thanks to all those that did not know us before. It was encouraging that there is so much interest in what we do.
I suspect we'll be back next year.
 |
| Mikey, Alex, Kev, Adrian(me), Thrall(orc) |
2012-10-11
OSPF is definitely a 4 letter word
I am coding OSPF support for the FireBricks now - and making some slow headway. So far all I have working is hello packets with DR and backup router election, dead router timeouts, and authentication. Given that this covers the general packet receipt processing and generation, it is quite a bit of progress even if it sounds like very little.
I have my head around the concepts of OSPF, but working through the mechanics is taking a while. The problem is that it is so different to BGP.
Normal routing within a router (OSPF or BGP) works on routes existing in a set in the device, with most specific always being picked for any destination. I.e. if you have a route for 10.0.0.0/8 (That is 10.0.0.0 to 10.255.255.255) and also a route for 10.2.3.0/24 (That is 10.2.3.0 to 10.2.3.255) then if a packet is being sent to 10.2.3.4 you send to the latter (most specific) route.
Where a router has more than one route to the same prefix (e.g. two separate routes for 10.2.3.0/24) then some process decides which is best. The actual sending of packets (the forwarding plane) does not need to know of the other, worse choice, routes - only the one it has to use (the best choice). The other routes still exist in the routing table though, so if the best route is removed, the next best takes its place.
There are however two means of sharing routes with other routers. OSPF and BGP are examples of these two main concepts, and they work very differently.
BGP works by telling peers (connected neighbouring routers) what routes it is using. I.e. what are those best choices it has made for each prefix. The protocol ensures that changes to this set of best choices are sent as they happen. The router receiving these includes them in its routing table, and still makes its best choice from all the routes it has, and its one best choice is what it tells its neighbours. One of the criteria for making the choice is how many systems the route has come through, and this allows the best overall path to be used for packets through many routers (e.g. across the Internet).
There is a big downside that if a link fails then all of the routes learned by that link have to be removed (perhaps leaving next best choices or removing routes all together). When the link comes back, all those have to be sent again. The knock on effect of changes to best choice will then be sent to neighbours, and spread around the Internet. Where a pair of routers exist, and so routes are passed on by both, the best choice one step removed is not a change, and so the ripples do not spread far. When multiple links fails so a route is totally removed, the effect is an update sent to the whole of the Internet!
However, each router only has the set of routes it knows itself and got from its immediate neighbours. It does not really need to know about anything further away. Its neighbours have already made the best choice decision on each route and passed on that final choice. As you get further from the source of a route, the best choice becomes less prone to change and so less necessary to pass on as a change.
This works well on the Internet, and is what is done between ISPs. One router knowing all routes held by all routers in the Internet would be somewhat difficult. Even the way BGP works the full table is over 400,000 routes now, and you get that from each transit provider with which you peer.
OSPF works differently, and its design is more suited to smaller networks generally. It works by every route known by every router in an area being known to every other router. This is potentially a lot more data, but if you are only using it to define the network, even one of a reasonable size ISP, it is not that daft. Often OSPF is used to ensure all devices in a network can see each other and then BGP is used to send the external Internet routes around the network.
OSPF therefore has to pass on all of this routing information. Each router is also told the topology of the network - routers and networks and links. This means that the path to send a packet can be worked out for the topology using Shortest Path First. The still boils down to each prefix having a place to go (the target for the first hop on the shortest path), though OSPF does throw in a complication of allowing equal paths to imply load balancing of traffic over more than one route.
The key difference here is that if topology changes, e.g. a link fails, then this is a small update to all routers to ensure that they all know the new topology and can decide on new shortest paths. The actual routes visible do not have to change or be re-sent. It is a bit of a trade off, as every router has to know more in the first place, but it makes the configuration of quite complex networks very simple.
To add to the simplicity, OSPF is usually something you just turn on on a router and it just works. There are settings and even security you can configure, but routers discover their neighbours automatically with multicast packets. This means you don't have to tell the routers the network topology - they work it out for themselves.
This is a lot simpler than BGP - though there is nothing in principle to stop BGP having such a discovery protocol, it does not normally, and requires manual configuration. The difference also reflects the typical usage - BGP used between ISPs and carefully and manually configured - often associated with a physical link being set up and even contracts signed. OSPF is used within a network and so just works with all of the devices that get connected in the network.
For FireBrick, the main use of OSPF is allowing the FireBrick to take part in this simple OSPF set up and to inject routes when used to connect people by L2TP or tunnels or VPNs so that the rest of the network just knows where to send traffic. It makes some sense.
Hopefully not a lot more work to do - it is a big learning exercise for me to understand the different conceptual model of OSPF and how to integrate in to the routing system in the FireBrick - but this is what makes coding fun.
Oh, and obviously coding OSPFv2 (IPv4) and OSPFv3 (IPv6) at the same time here.
I have my head around the concepts of OSPF, but working through the mechanics is taking a while. The problem is that it is so different to BGP.
Normal routing within a router (OSPF or BGP) works on routes existing in a set in the device, with most specific always being picked for any destination. I.e. if you have a route for 10.0.0.0/8 (That is 10.0.0.0 to 10.255.255.255) and also a route for 10.2.3.0/24 (That is 10.2.3.0 to 10.2.3.255) then if a packet is being sent to 10.2.3.4 you send to the latter (most specific) route.
Where a router has more than one route to the same prefix (e.g. two separate routes for 10.2.3.0/24) then some process decides which is best. The actual sending of packets (the forwarding plane) does not need to know of the other, worse choice, routes - only the one it has to use (the best choice). The other routes still exist in the routing table though, so if the best route is removed, the next best takes its place.
There are however two means of sharing routes with other routers. OSPF and BGP are examples of these two main concepts, and they work very differently.
BGP works by telling peers (connected neighbouring routers) what routes it is using. I.e. what are those best choices it has made for each prefix. The protocol ensures that changes to this set of best choices are sent as they happen. The router receiving these includes them in its routing table, and still makes its best choice from all the routes it has, and its one best choice is what it tells its neighbours. One of the criteria for making the choice is how many systems the route has come through, and this allows the best overall path to be used for packets through many routers (e.g. across the Internet).
There is a big downside that if a link fails then all of the routes learned by that link have to be removed (perhaps leaving next best choices or removing routes all together). When the link comes back, all those have to be sent again. The knock on effect of changes to best choice will then be sent to neighbours, and spread around the Internet. Where a pair of routers exist, and so routes are passed on by both, the best choice one step removed is not a change, and so the ripples do not spread far. When multiple links fails so a route is totally removed, the effect is an update sent to the whole of the Internet!
However, each router only has the set of routes it knows itself and got from its immediate neighbours. It does not really need to know about anything further away. Its neighbours have already made the best choice decision on each route and passed on that final choice. As you get further from the source of a route, the best choice becomes less prone to change and so less necessary to pass on as a change.
This works well on the Internet, and is what is done between ISPs. One router knowing all routes held by all routers in the Internet would be somewhat difficult. Even the way BGP works the full table is over 400,000 routes now, and you get that from each transit provider with which you peer.
OSPF works differently, and its design is more suited to smaller networks generally. It works by every route known by every router in an area being known to every other router. This is potentially a lot more data, but if you are only using it to define the network, even one of a reasonable size ISP, it is not that daft. Often OSPF is used to ensure all devices in a network can see each other and then BGP is used to send the external Internet routes around the network.
OSPF therefore has to pass on all of this routing information. Each router is also told the topology of the network - routers and networks and links. This means that the path to send a packet can be worked out for the topology using Shortest Path First. The still boils down to each prefix having a place to go (the target for the first hop on the shortest path), though OSPF does throw in a complication of allowing equal paths to imply load balancing of traffic over more than one route.
The key difference here is that if topology changes, e.g. a link fails, then this is a small update to all routers to ensure that they all know the new topology and can decide on new shortest paths. The actual routes visible do not have to change or be re-sent. It is a bit of a trade off, as every router has to know more in the first place, but it makes the configuration of quite complex networks very simple.
To add to the simplicity, OSPF is usually something you just turn on on a router and it just works. There are settings and even security you can configure, but routers discover their neighbours automatically with multicast packets. This means you don't have to tell the routers the network topology - they work it out for themselves.
This is a lot simpler than BGP - though there is nothing in principle to stop BGP having such a discovery protocol, it does not normally, and requires manual configuration. The difference also reflects the typical usage - BGP used between ISPs and carefully and manually configured - often associated with a physical link being set up and even contracts signed. OSPF is used within a network and so just works with all of the devices that get connected in the network.
For FireBrick, the main use of OSPF is allowing the FireBrick to take part in this simple OSPF set up and to inject routes when used to connect people by L2TP or tunnels or VPNs so that the rest of the network just knows where to send traffic. It makes some sense.
Hopefully not a lot more work to do - it is a big learning exercise for me to understand the different conceptual model of OSPF and how to integrate in to the routing system in the FireBrick - but this is what makes coding fun.
Oh, and obviously coding OSPFv2 (IPv4) and OSPFv3 (IPv6) at the same time here.
2012-10-10
Credit licence?
I am still trying to get my head around this whole consumer credit licence thing. I may try and get proper advice just so I know one way or the other. I have already paid their extortionate fee to renew, but who knows? I may be able to get a refund.
We have several ways we provide stuff to consumers, and I am not even 100% sure what counts as "credit" for a lot of what we do.
e.g. The typical broadband consumer pays the same every month, invoiced on the 1st and direct debited on the 1st or immediately after. The invoice is for that month, and so the payment is at the same time as we start providing the service - no "time to pay" and nothing on credit. Well, maybe if the 1st is on a Saturday and DD on Monday, but the way banks work mean the non banking days count as next banking day - so we see the money on 1st or in fact the night before at the latest. So not on credit!
Not all consumers work like that, but most could. Those that don't want 1st for DDs could be billed on a different phase in the month but still not on credit. But I am still not sure what counts as credit in this case. The way we normally work is that we don't expect to be paid until we raise the invoice. This means, if we invoiced, say, 14 days before the start of the month, or a month in advance, or even a month later, we would consider we are owed for that invoice from when we raise it. Some of those options may count as credit in the law, and some may not.
But what if we did invoiced later? Is the 5 working day time to advise a DD (we work on 5 working days not 10, as is allowed under DD rules, believe it or not) counted as credit? What if (like the regular monthly bills) we advised a DD and arranged for the DD to come out on the same day as the actual invoice. That means no "time to pay" from our point of view - not delay between invoice date and payment? Or is that not what credit means.
We do have a couple of snags. We supply routers, though normally that is free with the service, so no credit. Even so, we could arrange the invoice and DD to coincide. For new installs and even chargable routers and kit, we could ask the customer to agree a 2 working day collection by DD (that is allowed if per-case agreed with customer) which means we could get paid before an installation is complete - so we can again make it so not actually giving credit. We could even as for a fast payment bank transfer before shipping goods. We are not doing credit cards these days.
Indeed, it seems to me that we could make it that everything we do with consumers is not on credit at all, surely?
Though there are phone calls on VoIP and extra usage on broadband. That is tricky as it is not due until we invoice, as far as we are concerned, but we are allowing calls on credit I suppose. Maybe we should do a pre-pay for that? Would be possible to change to that. We are talking consumers not business here.
Even so, the Act mentions ongoing accounts, so what we do may simply not count anyway!
Or I could just pay up every few years. I suspect any professional advice would say "pay up" as that is the safe answer for any solicitor to say.
What worries me slightly is that this now has a surcharge towards the financial ombudsman or some such. I have dealt with an ombudsman before, and I am now concerned in case we are inadvertently liable to some other crowd of muppets. I am not in the business of lending money, and the last thing we need is someone referring us to a financial ombudsman. I would rather change the way we work than have that!
Obviously no changes proposed at the moment (we have renewed our licence) , but if we do find we are able to avoid the licence, and especially if we are tied in to some new ombudsman madness now, we may make changes. The good news is most consumers stay the same with a fixed bill and DD on 1st of each month so only a minor change for a few consumers, and no change for businesses.
Lets see what I find.
We have several ways we provide stuff to consumers, and I am not even 100% sure what counts as "credit" for a lot of what we do.
e.g. The typical broadband consumer pays the same every month, invoiced on the 1st and direct debited on the 1st or immediately after. The invoice is for that month, and so the payment is at the same time as we start providing the service - no "time to pay" and nothing on credit. Well, maybe if the 1st is on a Saturday and DD on Monday, but the way banks work mean the non banking days count as next banking day - so we see the money on 1st or in fact the night before at the latest. So not on credit!
Not all consumers work like that, but most could. Those that don't want 1st for DDs could be billed on a different phase in the month but still not on credit. But I am still not sure what counts as credit in this case. The way we normally work is that we don't expect to be paid until we raise the invoice. This means, if we invoiced, say, 14 days before the start of the month, or a month in advance, or even a month later, we would consider we are owed for that invoice from when we raise it. Some of those options may count as credit in the law, and some may not.
But what if we did invoiced later? Is the 5 working day time to advise a DD (we work on 5 working days not 10, as is allowed under DD rules, believe it or not) counted as credit? What if (like the regular monthly bills) we advised a DD and arranged for the DD to come out on the same day as the actual invoice. That means no "time to pay" from our point of view - not delay between invoice date and payment? Or is that not what credit means.
We do have a couple of snags. We supply routers, though normally that is free with the service, so no credit. Even so, we could arrange the invoice and DD to coincide. For new installs and even chargable routers and kit, we could ask the customer to agree a 2 working day collection by DD (that is allowed if per-case agreed with customer) which means we could get paid before an installation is complete - so we can again make it so not actually giving credit. We could even as for a fast payment bank transfer before shipping goods. We are not doing credit cards these days.
Indeed, it seems to me that we could make it that everything we do with consumers is not on credit at all, surely?
Though there are phone calls on VoIP and extra usage on broadband. That is tricky as it is not due until we invoice, as far as we are concerned, but we are allowing calls on credit I suppose. Maybe we should do a pre-pay for that? Would be possible to change to that. We are talking consumers not business here.
Even so, the Act mentions ongoing accounts, so what we do may simply not count anyway!
Or I could just pay up every few years. I suspect any professional advice would say "pay up" as that is the safe answer for any solicitor to say.
What worries me slightly is that this now has a surcharge towards the financial ombudsman or some such. I have dealt with an ombudsman before, and I am now concerned in case we are inadvertently liable to some other crowd of muppets. I am not in the business of lending money, and the last thing we need is someone referring us to a financial ombudsman. I would rather change the way we work than have that!
Obviously no changes proposed at the moment (we have renewed our licence) , but if we do find we are able to avoid the licence, and especially if we are tied in to some new ombudsman madness now, we may make changes. The good news is most consumers stay the same with a fixed bill and DD on 1st of each month so only a minor change for a few consumers, and no change for businesses.
Lets see what I find.
Sorry, BT can't find the National Gallery
It seems that BT can't find The National Gallery on Trafalgar Square because there is no street address number.
No, I am serious here. We even have the recording from the message the BT Engineer left for our customer on this.
To add to the fun, this was for a fault visit, i.e. where BT are visiting the place they installed a phone line previously. It is not a case where we tell them where to go for a new install, and so we could not have made a mistake, it is a matter of them going where they put the phone line in order to fix it!
Looking at the picture from their web site, I'd say the place is hard to miss!
Sadly, in this case, it means a re-appointment for our customer, which is an extra delay. Sorry about that, and thanks for letting us share this.
2012-10-09
Regulators that can't tell you if you need a licence?
We get this crap with OFCOM all the time - they are the only body able to actually enforce several regulations which apply to telcos, and the regulations are ambiguous at best in many areas.
They have to be able to interpret the regulations and understand if a telco is complying or not in order to enforce them.
The same is true with the OFT and the consumer credit licences.
Yet, if you ask - do we comply? or do I need this licence? or whatever - they say they cannot advise us!
But they are the only people that know for sure, short of a court case. If they say "no, we are not going to prosecute you" then that is definitive as they are the only body that can.
So why the hell will they not say.
Latest stupidity is a consumer credit licence. We have one, but the renewal is nearly three times the cost of last time, and we wonder if we need one. We don't lend money. We sell ongoing services on an ongoing account cleared every month by DD. Their own literature only talks of selling goods on credit, not services, and various services about lending money which is not what we do generally. If we could understand their rules we could work out if we need a licence, or change the way we do business in some cases to ensure we don't need one. But they are no help.
Yet they cannot answer, even telling them clearly what we do and how we do it, they refuse to say. They say they cannot know the ins and outs of a business. When WTF, (a) we just told them, and (b) they have to be able to assess the ins and outs of a business and interpret the Act in order to do their job. They must have those skills...
What is worse, they send a document with advise that specifically lists and email address we can contact to ask about interpretation of the Act. Yay! But it is a broken email address, and they won't tell us the correct email address, just that they cannot advise.
Arrrrrg!
So, blackmailed in to getting a licence renewal. Not amused.
They have to be able to interpret the regulations and understand if a telco is complying or not in order to enforce them.
The same is true with the OFT and the consumer credit licences.
Yet, if you ask - do we comply? or do I need this licence? or whatever - they say they cannot advise us!
But they are the only people that know for sure, short of a court case. If they say "no, we are not going to prosecute you" then that is definitive as they are the only body that can.
So why the hell will they not say.
Latest stupidity is a consumer credit licence. We have one, but the renewal is nearly three times the cost of last time, and we wonder if we need one. We don't lend money. We sell ongoing services on an ongoing account cleared every month by DD. Their own literature only talks of selling goods on credit, not services, and various services about lending money which is not what we do generally. If we could understand their rules we could work out if we need a licence, or change the way we do business in some cases to ensure we don't need one. But they are no help.
Yet they cannot answer, even telling them clearly what we do and how we do it, they refuse to say. They say they cannot know the ins and outs of a business. When WTF, (a) we just told them, and (b) they have to be able to assess the ins and outs of a business and interpret the Act in order to do their job. They must have those skills...
What is worse, they send a document with advise that specifically lists and email address we can contact to ask about interpretation of the Act. Yay! But it is a broken email address, and they won't tell us the correct email address, just that they cannot advise.
Arrrrrg!
So, blackmailed in to getting a licence renewal. Not amused.
Warning!
I am sure that once upon a time warning signs were used to actually warn people where there were a significant (even if small) number of people unaware of some possible danger. There are places for such things. Indeed, instructions for fire exits on a hotel door are a case: where we all know what to do, not because we have survived several hotel fires, or know people that have, but because we have read the signs.
Once upon a time you had to pay a sign writer to put up a sign, so they were generally sensible - used only where it was worth the money to put up a sign.
I am not alone in the pet hate at warning signs, but really, do we live in a world where a hotel could be sued because someone did not know to "take care when standing or walking on wet surfaces" ?
I mean, who is their target audience for this sign? People old enough to read, and have unsupervised access to a hotel shower, but stupid enough to have not learned that wet floors are slippery? Do such people actually exist? Does the world really allow that lack of common sense to somehow be the hotel's fault?
If we really live in such a crazy world, surely a simple sign like this cannot be sufficient to make the hotel blameless? E.g. if I slipped, and broke my arm - I could sue.... and...
(a) They could not really say "you should know that wet floors are dangerous" can they? If that was true then they would not need signs. They clearly expect there to be guests that do not know this.
(d) Also, they somehow expect that I failed to learn this lesson in several decades of my life up until now, so surely they are naive to think that a simple sign will somehow give me an epiphany and educate me on the dangers of wet floors. They must have known that teaching me about wet floors would take way more than just a silly sign - after all, they think I have not learned this in well over 40 years of life so far.
So surely that would make them negligent for not insisting I go on a three day common sense training course, with tests I have to pass, before entering the building?
Yes, crazy, but surely as crazy as any excuse for needing such a stupid sign in the first place?!
What if someone did a "common sense training course", with a test. Then when you book a hotel they just need a tick box "have you passed your common sense training course" and never need a stupid sign again. :-)
Once upon a time you had to pay a sign writer to put up a sign, so they were generally sensible - used only where it was worth the money to put up a sign.
I am not alone in the pet hate at warning signs, but really, do we live in a world where a hotel could be sued because someone did not know to "take care when standing or walking on wet surfaces" ?
I mean, who is their target audience for this sign? People old enough to read, and have unsupervised access to a hotel shower, but stupid enough to have not learned that wet floors are slippery? Do such people actually exist? Does the world really allow that lack of common sense to somehow be the hotel's fault?
If we really live in such a crazy world, surely a simple sign like this cannot be sufficient to make the hotel blameless? E.g. if I slipped, and broke my arm - I could sue.... and...
(a) They could not really say "you should know that wet floors are dangerous" can they? If that was true then they would not need signs. They clearly expect there to be guests that do not know this.
(d) Also, they somehow expect that I failed to learn this lesson in several decades of my life up until now, so surely they are naive to think that a simple sign will somehow give me an epiphany and educate me on the dangers of wet floors. They must have known that teaching me about wet floors would take way more than just a silly sign - after all, they think I have not learned this in well over 40 years of life so far.
So surely that would make them negligent for not insisting I go on a three day common sense training course, with tests I have to pass, before entering the building?
Yes, crazy, but surely as crazy as any excuse for needing such a stupid sign in the first place?!
What if someone did a "common sense training course", with a test. Then when you book a hotel they just need a tick box "have you passed your common sense training course" and never need a stupid sign again. :-)
2012-10-07
Heartless git?
Today, almost every bloody advert break is trying to get me to pay money to help starving kids somewhere. It is not just one charity. I think there are at least three. Apparently 22,000 children will die today! Do they pick Sundays specially for some reason?
Now, just to be clear, I am not a heartless git, honest, though I am sure my kids would rather I gave them money than to a charity. So what is winding me up?
1. The adverts are very specifically targeting empathy and parental instincts in us all - deliberately exploiting the way most people's minds work with images of a starving kid on screen. That annoys me! I always look for the real meaning in any advert, and this just winds me up. If I am going to donate to a charity I want it to be my choice, not someone cleverly making an advert to trigger an emotional response. The effect is negative, in my case. I deliberately avoid these charities because of the tactic.
2. Whilst I am not one to be convinced by most of the environmental crap we see these days, it seems somewhat hypercritical that these adverts are not also required to state the environmental impact. How much CO2 is produced by saving one child? Not that saving a child is not worthwhile, but if they did state the environmental impact of one more person on the overpopulated planet in such adverts, it would make the car adverts stating CO2 emissions look meaningless irrelevant...
So, proper rant today, sorry...
I'll go back to watching TV.
2012-10-05
Found RF interference - won't tell anyone.
Seriously, can a simple grid reference be considered "personal information" and so subject to DPA? Even an address is not something that inherently identifies a living individual.
BT will send engineers to find the source of radio interference (REIN) affecting a DSL line. But they won't actually tell anyone what they find. They won't even provide a grid reference where they found RF! They blame the DPA first, and then insist that they (BT plc) don't have the information, but the REIN team (BT plc) have it and will not tell them. This is a communication company point blank refusing to communicate with themselves to the detriment of the customer and it really pisses me off.
Am I too mean? My latest reply to them:-
Stop doing that now.
I am asking you, British Telecommunications plc, for information that British Telecommunications plc have.
Stop refusing to communicate with YOURSELF - you are ONE COMPANY, ONE LEGAL ENTITY and are a COMMUNICATION COMPANY. Your constant refusal to communicate internally is demonstrating how totally INEPT and INCOMPETENT you are as an organisation and I am totally fed up with it.
As a shareholder in BT Group plc the sole shareholder of British Telecommunications plc, the company that has the data we are asking for, please provide the data. Also explain to this shareholder why you have wasted money getting information that you are refusing to provide. Do not make up crap about DPA. I am not asking for any PERSONAL INFORMATION. I am asking where you detected RF, a grid reference, nothing personal.
Try again.
If you once again even suggest or imply that any other part of British Telecommunications plc is a different entity from any part of British Telecommunications plc that you work for, as any sort of excuse to not do something, I will have to consider that a knowingly false or misleading statement that is for the purpose of some gain on your part (to avoid work) or to some detriment on my part (even just to annoy me), both of which constitute a criminal breach of the Fraud Act. Is that clear?
I am really really fed up with this crap.
P.S. There are people that will say "this is what the industry asked for". I did not ask for this. And I am sure the industry did not ask for BT to use this as a way to cause more problems to customers or for BT to start lying to us. Regardless of OFCOM rules, BT plc is a single entity, and they cannot escape that.
BT will send engineers to find the source of radio interference (REIN) affecting a DSL line. But they won't actually tell anyone what they find. They won't even provide a grid reference where they found RF! They blame the DPA first, and then insist that they (BT plc) don't have the information, but the REIN team (BT plc) have it and will not tell them. This is a communication company point blank refusing to communicate with themselves to the detriment of the customer and it really pisses me off.
Am I too mean? My latest reply to them:-
Stop doing that now.
I am asking you, British Telecommunications plc, for information that British Telecommunications plc have.
Stop refusing to communicate with YOURSELF - you are ONE COMPANY, ONE LEGAL ENTITY and are a COMMUNICATION COMPANY. Your constant refusal to communicate internally is demonstrating how totally INEPT and INCOMPETENT you are as an organisation and I am totally fed up with it.
As a shareholder in BT Group plc the sole shareholder of British Telecommunications plc, the company that has the data we are asking for, please provide the data. Also explain to this shareholder why you have wasted money getting information that you are refusing to provide. Do not make up crap about DPA. I am not asking for any PERSONAL INFORMATION. I am asking where you detected RF, a grid reference, nothing personal.
Try again.
If you once again even suggest or imply that any other part of British Telecommunications plc is a different entity from any part of British Telecommunications plc that you work for, as any sort of excuse to not do something, I will have to consider that a knowingly false or misleading statement that is for the purpose of some gain on your part (to avoid work) or to some detriment on my part (even just to annoy me), both of which constitute a criminal breach of the Fraud Act. Is that clear?
I am really really fed up with this crap.
P.S. There are people that will say "this is what the industry asked for". I did not ask for this. And I am sure the industry did not ask for BT to use this as a way to cause more problems to customers or for BT to start lying to us. Regardless of OFCOM rules, BT plc is a single entity, and they cannot escape that.
2012-10-04
Meet Ignis...
This is Ignis, which is Latin for "fire". Ignis is the new mascot for FireBrick, and will have a 1,000 colleagues in "up to 3 months starting after the current Chinese national holiday" or some such. We are hoping for before Christmas, but you never know.
We are going to try and get people to upload pictures of odd places that Ignis has traveled and been photographed. We're kicking it off with the revolving restaurant at the top of the BT Tower in London. Once upon a time the restaurant was open to the public, but these days it is somewhat more exclusive with airport style security to get in. Fortunately the BTW ISP forum is held there and people like myself are allowed in. So this is Ignis at the BT Tower.
We should have something, probably a facebook page, for him sorted before we actually have a shed full of them and start handing them out. In the mean time, Ignis will be on the FireBrick stand at this year's IPExpo in Earls Court 2 in a couple of weeks, keeping a close eye on the orc. We may even have him at UKNOF next week.
Here's Ignis with a nice view of docklands and The Shard...
2012-10-03
Is it true that a picture of a cat will get more hits?
I have to wonder what adverts pop up for a picture of a cat?
The Pashley bike post just got adverts for a different bike manufacturer.
And before some smart arse comments on the card number, yes, gimp (windows users read "photoshop") is great, isn't it... :-)
2012-10-02
Bike shops
Berkshire Cycles seem to be causing me a few problems at the moment.
For a start, when my wife purchased a new Pashley bike and bike rack from them (Reading branch), they fitted the rack and bike to the car (which was nice). She drove the couple of miles to Wokingham only to find that they fitted the bike so it rubbed against the boot paintwork. Not a good look for a new BMW! I'll send them the bill and see what happens.
We then took two Pashley bikes in to the shop for a service. My bike had a broken bell and loose chain, which we pointed out.
First off they say that the bell is a problem, and it will be a few days. They call back to say it is ready but when my wife gets to the shop they say that it is not as they did a test ride and found another problem!
When we finally get it back, two weeks later (walking to work every day!) they have not in fact changed the bell. They say that they still don't have them in. You could not sell a bike new like that, it would be illegal. Funny how I have just gone on to google, searched for a Pashley bell, and found a supplier with them in stock for next day delivery. It is not like I can't fix a bike myself - I used to when I was a kid, and the bike is the same Sturmey Archer gears I had back then. I like my Pashley. But these days I am not that inclined to get my hands dirty which is why they got nearly £200 to service two bikes.
Of course they did do some work - the chain is no longer loose. Well, it was not, but cycling a couple of miles I find that the wheel is not actually done up tightly and now has slipped. I had to walk back to the office to find a spanner and tighten it as the wheel was now rubbing against the frame. Again, not funny. Getting fed up with walking.
For some obscure reason, they also decided to move the gear changer so it is now out of reach when my hand is on the handle bars. Why do that? I have found a screwdriver and fixed that too.
Overall, I have to say, not impressed with Berkshire cycles. They are the only Pashley dealer near here though, sadly.
It is a shame that nobody seems to put the same care and attention to detail in to their work these days. I must be getting old.
P.S. After the "service" my lights no longer work, when at least one did before - arrrrg!
We then took two Pashley bikes in to the shop for a service. My bike had a broken bell and loose chain, which we pointed out.
When we finally get it back, two weeks later (walking to work every day!) they have not in fact changed the bell. They say that they still don't have them in. You could not sell a bike new like that, it would be illegal. Funny how I have just gone on to google, searched for a Pashley bell, and found a supplier with them in stock for next day delivery. It is not like I can't fix a bike myself - I used to when I was a kid, and the bike is the same Sturmey Archer gears I had back then. I like my Pashley. But these days I am not that inclined to get my hands dirty which is why they got nearly £200 to service two bikes.
Of course they did do some work - the chain is no longer loose. Well, it was not, but cycling a couple of miles I find that the wheel is not actually done up tightly and now has slipped. I had to walk back to the office to find a spanner and tighten it as the wheel was now rubbing against the frame. Again, not funny. Getting fed up with walking.
Overall, I have to say, not impressed with Berkshire cycles. They are the only Pashley dealer near here though, sadly.
It is a shame that nobody seems to put the same care and attention to detail in to their work these days. I must be getting old.
P.S. After the "service" my lights no longer work, when at least one did before - arrrrg!
2012-10-01
Not quite "OSPF for Dummies"...
To be honest, not that bad, on the second reading. I think I am getting the hang of it now.
Plan is to start adding OSPF to FireBricks some time tomorrow.
I really hope this is not one of those protocols that leaves me pulling my hair out. Watch this space...
Subscribe to:
Posts (Atom)
FB9000
I know techies follow this, so I thought it was worth posting and explaining... The FB9000 is the latest FireBrick. It is the "ISP...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...