Sharp microwaves
My Samsung microwave died last March. It makes sparks from the magnetron. I tried a bit to see if I could get a new one, but it's annoyingly difficult, since the magnetron is half the cost of the unit.
I'd really like to buy a microwave not-made-in-China. Sharp is reported to make them in Japan, assemble them in the USA.
But, I can not find a store that sells them. I'd really like to touch one before I buy it.
Sharp microwaves
My Samsung microwave died last March. It makes sparks from the magnetron. I tried a bit to see if I could get a new one, but it's annoyingly difficult, since the magnetron is half the cost of the unit.
I'd really like to buy a microwave not-made-in-China. Sharp is reported to make them in Japan, assemble them in the USA.
But, I can not find a store that sells them. I'd really like to touch one before I buy it.
no-op instructions for ARM
At http://www.credil.org/ we had to deal with some code that was not yet GPL compliant, fixing bugs (removing features!) from a .so file that we had. We had some of the source code, but not enough to recompile it.
We needed to disable certain calls, so we disassembled the object file with objdump -d. We then reviewed the code, looked for the calls we wanted to remove, which are "bl" instructions.
../../prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-objdump -d libmyso.so >libmyso.S
All branch instructions are conditional, but one valid condition is "branch always" (and link, which means it's a subroutine). See: http://www.peter-cockerell.net/aalp and http://www.peter-cockerell.net/aalp/html/frames.html, section C which is at: http://www.peter-cockerell.net/aalp/html/app-c.html
Just look, if we change 'e' to 'f', it becomes Branch Never! We tried that.
Oops, this doesn't work. Peter Cockerell's book (from 1987) documents ARMv3, and we are up to ARMv9. It seems that his bit pattern now means to branch, and change to THUMB mode... The clue that this is what happens is that when we disassembled the result we saw "blx", but the real clue was that the offset was no longer "place", instead was "place+2". Thumb instructions are 16-bit big.
See http://www.keil.com/support/man/docs/armasm/armasm_cihfddaf.htm for details of BLX.
So, how to create a NOP? We didn't see an official one. Some googling revealed that "MOV R0 R0" is a good choice.
http://www.keil.com/support/man/docs/armasm/armasm_cjafcggi.htm
To assemble this:
First nibble is 0b1110 (15, 0xE) for "Always".
Second nibble is 0b0001 (1, 0x1), for 00, Immediate bit = 0, first bit of opcode is 1. (The Opcode is 0b1101 (14, 0xD) for MOV)
Third nibble is 0b1010 (10, 0xA), three bits of opcode, S bit set to 0.
Fourth nibble is 0x0000 (R0), and Fifth nibble is 0x0000 (R0).
The last 12 bits are 0.
The result is: 0b1110 0001 1010 0000 0000 0000 0000 0000. Or 0xE1A00000.
We didn't realize that the Android phones are in big-endian mode, so when we searched for the right instructions to change, we did not find them.
When you objdump a .so file, it's mapped directly, so the offsets that objdump products are actual file offsets.
no-op instructions for ARM
At http://www.credil.org/ we had to deal with some code that was not yet GPL compliant, fixing bugs (removing features!) from a .so file that we had. We had some of the source code, but not enough to recompile it.
We needed to disable certain calls, so we disassembled the object file with objdump -d. We then reviewed the code, looked for the calls we wanted to remove, which are "bl" instructions.
../../prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-objdump -d libmyso.so >libmyso.S
All branch instructions are conditional, but one valid condition is "branch always" (and link, which means it's a subroutine). See: http://www.peter-cockerell.net/aalp and http://www.peter-cockerell.net/aalp/html/frames.html, section C which is at: http://www.peter-cockerell.net/aalp/html/app-c.html
Just look, if we change 'e' to 'f', it becomes Branch Never! We tried that.
Oops, this doesn't work. Peter Cockerell's book (from 1987) documents ARMv3, and we are up to ARMv9. It seems that his bit pattern now means to branch, and change to THUMB mode... The clue that this is what happens is that when we disassembled the result we saw "blx", but the real clue was that the offset was no longer "place", instead was "place+2". Thumb instructions are 16-bit big.
See http://www.keil.com/support/man/docs/armasm/armasm_cihfddaf.htm for details of BLX.
So, how to create a NOP? We didn't see an official one. Some googling revealed that "MOV R0 R0" is a good choice.
http://www.keil.com/support/man/docs/armasm/armasm_cjafcggi.htm
To assemble this:
First nibble is 0b1110 (15, 0xE) for "Always".
Second nibble is 0b0001 (1, 0x1), for 00, Immediate bit = 0, first bit of opcode is 1. (The Opcode is 0b1101 (14, 0xD) for MOV)
Third nibble is 0b1010 (10, 0xA), three bits of opcode, S bit set to 0.
Fourth nibble is 0x0000 (R0), and Fifth nibble is 0x0000 (R0).
The last 12 bits are 0.
The result is: 0b1110 0001 1010 0000 0000 0000 0000 0000. Or 0xE1A00000.
We didn't realize that the Android phones are in big-endian mode, so when we searched for the right instructions to change, we did not find them.
When you objdump a .so file, it's mapped directly, so the offsets that objdump products are actual file offsets.
An open Letter to Shaw Direct
Dear Jim,
You write, "Over the last 8 years, we have seen huge advances in the technology of our receivers without an impact on the MRF. Effective Feb. 1, 2010, the monthly rate for MRF (multiple receiver fee) will increase by $1/month to $5.99/month"
Over the past 8 years this is simply not true.
When I signed up in the summer of 2001, there was no multiple receiver fee. So, the MRF fee has in fact gone up by $5 over the last 8-9 years.
Meanwhile, my receiver is still the same VERY SLOW piece of crap motorola receiver you made me buy in 2001. I've seen no improvement in technology at all, and I'm locked into buying crappy, closed source, proprietary receivers if I want to receive your signal. You make me pay for the equipment, and then prevent me from using it the way I want.
When I first signed up, you gave me this "credit" on programming, but you made me spend it on your premium package, rather than on the basics package that I wanted, which meant that the receiver really cost me 2x as much as I was lead to believe.
The packages are such that I get hundreds of channels I do not want, and I can not get the two or three channels that I want without huge expense.
Meanwhile, the number of Pay-per-vue channels continues to decrease (and most of them are porn), I guess because you never bothered to offer your loyal customers an upgrade to the oval dish, and I can only see one of the two satellites.
If hulu.com opens in Canada, you can kiss my business goodbye.
If any local TV stations disappear from my dial, you can kiss my business goodbye. If you pass on any local TV tax to me, then I can assure that I will simply cut my bill by that same amount, or give up, and just watch DVDs.
Syndicated 2010-01-04 15:35:00 (Updated 2010-01-06 04:05:25) from Michael's musings
IPv6 with mcast UserModeLinux backends
I am doing some work with IPv6. (see http://bluerose.sandelman.ca/projects/show/unstrung )
I have a test network shown at: http://bluerose.sandelman.ca/repositories/changes/unstrung/doc/network-1.png
In automated testing I would normally use the daemon mode, with uml_netjig. In casual use, I was using the mcast backend, because it has fewer moving parts.... but my network interfaces kept remaining in state "tentative" and I could not send packets.
What was the problem, I debugging for awhile through the IPv6 code, and finally thought that it had something to do with the UserModeLinux network interface never providing low-level LINK "UP" signal, and so it never did Duplicate Address Discovery, and remove the tentative mark.
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::1000:ff:fedc:bcff/64 scope link tentative
valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::1000:ff:fe64:6423/64 scope link tentative
valid_lft forever preferred_lft forever
Note that it says "tentative".
NO! DAD was occuring just fine, but it FAILS. Why? Because it thinks it has a duplicate... finally I noticed
eth0: duplicate address detected! eth1: duplicate address detected!
Why is this? It's because the mcast interface gets a copy of the packets that are output. I.e. it hears itself. DAD should work even when that happens, I think.
I need to look at whether the mcast interface should be fixed (remember it's own packets and ignore them? Drop packets that originate from it's own MAC address?), or should DAD be fixed?
IPv6 with mcast UserModeLinux backends
I am doing some work with IPv6. (see http://bluerose.sandelman.ca/projects/show/unstrung )
I have a test network shown at: http://bluerose.sandelman.ca/repositories/changes/unstrung/doc/network-1.png
In automated testing I would normally use the daemon mode, with uml_netjig. In casual use, I was using the mcast backend, because it has fewer moving parts.... but my network interfaces kept remaining in state "tentative" and I could not send packets.
What was the problem, I debugging for awhile through the IPv6 code, and finally thought that it had something to do with the UserModeLinux network interface never providing low-level LINK "UP" signal, and so it never did Duplicate Address Discovery, and remove the tentative mark.
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::1000:ff:fedc:bcff/64 scope link tentative
valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::1000:ff:fe64:6423/64 scope link tentative
valid_lft forever preferred_lft forever
Note that it says "tentative".
NO! DAD was occuring just fine, but it FAILS. Why? Because it thinks it has a duplicate... finally I noticed
eth0: duplicate address detected! eth1: duplicate address detected!
Why is this? It's because the mcast interface gets a copy of the packets that are output. I.e. it hears itself. DAD should work even when that happens, I think.
I need to look at whether the mcast interface should be fixed (remember it's own packets and ignore them? Drop packets that originate from it's own MAC address?), or should DAD be fixed?
Profit on Farmville
I'm level 14 on Facebook's Farmville. Why do I play? Because my 4yr old likes it. Of course, I want to maximize my profit.
I only run it about once a day, so crops that wither before I can harvest them are out, but what next? It costs 15 coins to plow the field each time.
It turns out that longer growing crops aren't worth much more. I did a spreadsheet to work things out.
<pre>cost sell harvest profit profit/day wheat 35 115 3.0 65 21.7 eggplant 25 88 2.0 48 24.0 artichokes 70 204 4.0 119 29.8 daffodils 60 135 2.0 60 30.0 squash 40 121 2.0 66 33.0 soybeans 15 63 1.0 33 33.0 cotton 75 207 3.0 117 39.0 bell-peppers 75 198 2.0 108 54.0 aloe vera 56 85 0.2 14 56.0 strawberries 10 35 0.2 10 60.0 cranberries 55 98 0.4 28 67.2 pumpkin 30 68 0.3 23 69.0 rice 45 96 0.5 36 72.0 peppers 70 162 1.0 77 77.0 raspberries 20 46 0.1 11 132.0 </pre>
Raspberries take 2 hours. Sometimes worth it, but the profit margin is very low unless you do it all day long.
Ruling out the things that take less than a day, leaves me with peppers, bell-peppers, and cotton as the highest grossing.
Too bad that the market price didn't depend upon other factors, like how many other people were growing it... or if you grew some things properly, you could keep the seed.
Or maybe you have to rotate your crops. Or grow eggplants next to pumpkin will keep away the racoons, or the blight.
Syndicated 2009-12-02 00:49:00 (Updated 2009-12-27 04:08:24) from Michael's musings
Port forwarding from something not your firewall
I have a number of web servers which want to express their port 443 to the world. These machines also have IPv6, and that's what I hope many clients will use. Since HTTPS servers can not do virtual hosting, and port 443 on CREDIL's firewall is already taken, what can I do?
We have other public IPs, with other (virtual) machines that have internal and external connections. I could use their port 443s.
I previously did this for port-119 (NNTP). I had set things up like:
iptables -A PREROUTING -d ${myexternalip}/32 -p tcp -m tcp --dport 119 -j DNAT --to-destination ${serverinternalip}:119
iptables -A POSTROUTING -d ${serverinternalip}/32 -p tcp -m tcp --dport 119 -j MASQUERADE
The first statement is relatively ordinary. Change the destination address. The second statement is annoying. It is critical on machines when the default route does not point at it. Basically, it changes the source IP that connects to the ${myinternalip} to be the internal address of the firewall.
This actually necessary even on the default route: without this, internal connections to port 119 do not work — this is because the internal machine sees a connection originating from the internal client IP, to the internal IP. The problem is that the internal client actually has a connection from it's IP, to the external IP of the firewall.
The above method works fine, except.... the internal machine sees the connection as being from the internal IP of the firewall. That really sucks from a point of view of logging!
How to solve it? The problem is that packets with an origin of port 443 needs to go to the other machine... this is what I did:
On the gateway machine:
iptables -A PREROUTING -d ${myexternalip}/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination ${serverinternalip}:443
On the target machine:
iptables -A OUTPUT -t mangle '!' -d ${myinternalnetwork}/24 -j MARK --set-mark 443
ip rule add fwmark 443 table 443
ip route add 0.0.0.0/0 via ${myinternaliP} table 443
It's very important that you set the mark using the mangle chain. It will not work on the NAT or the regular OUTPUT chain!
The result is now that packets with origin port 443, go via this alternate firewall, and the web server itself will see the correct originating IP.
Syndicated 2009-11-25 13:21:00 (Updated 2009-12-02 06:10:56) from Michael's musings
Xmas lights with white cords
Apparently, at Canadian Tire, and online, if I want multicolour Xmas lights (ideally LEDs), that I have to have a green cord. Only white cords are with white LEDs.
I considered buying one of each and moving the "bulbs", but many of the systems are not socketed.
I want Xmas lights I can put up on the house, staple in, and LEAVE there.
Syndicated 2009-11-23 13:16:00 (Updated 2009-11-25 19:13:14) from Michael's musings
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!