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).
2012-10-20
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.
Subscribe to:
Posts (Atom)
QR abuse...
I'm known for QR code stuff, and my library, but I have done some abuse of them for fun - I did round pixels rather than rectangular, f...
-
This is an appeal for (sensible) comments. I am working on revised A&A tariffs for broadband. For those that are not sure how they wor...
-
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... -
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...