Have you actually tried blocking the signal with a Faraday cage?
At work, coworkers sometimes forget their mobile phone on their desks when going to lunch. If the phone rings then we do something about it, such as locking it into a heavy-duty transportation box, hiding it under their desk, etc. Last time we put a coworker's iphone into a cookie tin (ok, the tin was not strictly a cookie tin but a flat tin can used for yummy Tunesian pastries, but I digress). The iphone lost signal. After the coworker came back and we had discussed Faraday cages we put the iphone into a different tin can (one used for Malaysian sweets) but it kept the signal. Puzzled, we tried with a different brand of mobile phone (HTC I believe) - it kept the signal inside both tin cans.
Conclusions:
- The iPhone antenna is worse than that particular HTC
- Blocking radio signals is hard.
The next experiment we are going to do will involve grounding the tin can. (preferably in a new tin box so we have a change to eat pastries again).
I had to switch to 802.11a because the 2.4GHz spectrum where I live is mostly saturated. I can see ~25 2.4GHz networks and at 2.4GHz I could get approximately 5-10Mbps throughput. In 5GHz I can get approximately 20Mbps throughput. The AP was more expensive but in addition to dual 2.4/5GHz mode I also got other "business" goodies such as VLAN, multiple SSID, decent documentation, PoE, etc.
I do see other 802.11a networks here (about 3) that apparently belong to the national telco.
Right now where I live: 1C and 97% relative humidity.
The important thing about humidity is that it is non-condensing (i.e. not raining) and that the temperature of the device is kept above the dew point (otherwise water condenses on and inside the device). So:
- dropping it in the bath tub: bad
- using it in fog: bad
- taking a cold device (eg. 5C) from the outside to the inside where the temperature is higher but relative humidity is also high: bad
I don't see how captive portals that rely on DNS tricks will work.
For those who don't know: A captive portal is used for directing you webbrowser to a specific page, eg. when you access a for-pay wireless network and it redirects you to a webpage where you can log in or sign up. One mechanism is to capture the DNS query packet, and respond with, say, 192.168.0.1, where that server will respond with either a HTTP 301 redirect or the login-page. I cannot see how this will work with DNSSEC because the fake response will be be signed. Another mechanism is to only redirect the HTTP request and respond with a 301 or login page. This should still work with DNSSEC.
So the big players, are probably a bit reluctant to enable DNSSEC on their domain because of the users that happen to sit behind the first type of captive portal.
I actually dislike the first mechanism, because even when it can be implemented nicely, many captives portals forget to set DNS response lifetime to 0 seconds so that when you have signed in/up, your DNS resolver will retry the query. Webbrowser reload only results in the you getting the login page again. So when connecting to a wifi network I don't know the details about I always first go to a webpage that I don't want to go to.
I recently switched from 2.4GHz (802.11b/802.11g) to 5GHz (802.11a) for the same reason. Where I live I can see approximately 23 networks using 2.4GHz, and the real speed I get out of the 2.4GHz band is *maybe* 6Mbit/s. Full signal strength, but there is so much congestion in the band that the actual throughput is pathetic.
After I switched to 5GHz I get roughly 25Mbit/s consistently.
I didn't try 802.11n because my laptop + mac mini does not support that, and if the 2.4GHz band is that congested then it is not very likely that a more greedy approach to using the 2.4GHz band would have helped.
There will always be a risk of information loss or small distortion of meaning, because languages are not equal.
Slang and sayings are probably the most difficult to translate. Eg. translating the English word "blue" to Italian will force you decide between "blu" and "azzurro" and either of those two choices insert extra meaning that wasn't in the original. Another example is the Danish saying "Træerne vokser ikke ind i himlen" which as far as I know has no direct equivalent in English.
My guess is that having the domains in that order allows you copy them directorly to/from DNS packets. And the reason for the order in the DNS packets is that it allows compression by back-references. Roughly if a packet contains multiple names:
some.domain.example.com
other.domain.example.com can be transmitted like:
some.domain.example.com
other<go back in packet at offset X>
So why do we seem to have teenage girls blossoming so early? I'd wager that it is the use of hormones in cows that has artificially accelerated the aging process among humans.
No, it is better nutrition and a resulting earlier increase of leptin production. Plente of google results. Best hit seems to be "Human Reproductive Biology" by Jones/Lopez (google view of book)
Solaris. Sun has maintained backward compatibility for applications for decades. You rarely encounter "oops, you need libc.2.0, but that is not supported on the newer kernels.". Also, the command-line system administration tools (especially for troubleshooting) are comprehensive (dtrace, truss, ptree, prstat, psrset,...)
Documentation at your hands, and timestamped
on
Documenting a Network?
·
· Score: 3, Insightful
If you are in the server room, and you have: A: a spreadsheet that your predecessor made. B: a post-it note on the switch saying it what it does. Which one do you trust?
For the physical/low-level network the documentation should be in the network. Just like source code should contain comments about this particular piece of code, a similar approach works reasonably for the physical network. I see no point in a having an outdated spreadsheet. It is more useful that the cables and ports are labelled and numbered, that there is a post-it note on a switch say where the links go, etc. The grand overview should be in electronic form, though. A scanned hand drawing is fine. A photo of a whiteboard drawing is fine too.
For the logical network put comments whereever possible. On settings, VLAN configurations, server connections, account setups,... Again, the grand overview should be in electronic form.
I have found it useful that the information is timestamped, so you know when it was last valid.
You mention flavors of BSD and signal handling. Perhaps http://lists.apple.com/archives/darwin-kernel/2005/Aug/msg00133.html may be helpful next time you encounter this. If OSX borrowed the signal handling code from the BSD relatives, it could be this. In that case it is probably a different bug on linux.
In any case an unkillable process is a kernel bug (as long as NFS and cluster software is not involved).
There is a common wait to do this. I am not sure if it counts as a solution or a kludge: - set socket into non-blocking mode - call connect() - check for immediate success (happens on solaris over loopback interface) - if not: - select/poll for writability, using a timeout - When writable, retrieve connection status with getsockopt()
So yes, a timeout parameter to the connect() call would make life easier for client applications. But there is a workaround.
sometimes even a "kill -9" won't kill the process That sounds odd. Which OS was that?
Do you happen to know of any uses of this protocol in real applications? Diameter applications (rfc3588). SS7 can be transported over SCTP. I have been in contact with people using SCTP for high-performance cluster computing, but I don't know the details.
There are experimental work on HTTP-over-SCTP. At one point it seemed that streaming applications could benefit from SCTP's lack of head-of-line blocking, but recently it seems that DCCP is a better fit for those applications.
True. Perhaps my viewpoint is a bit nonstandard because I also developed some of the wrappers in lksctp, and had to deal with some of the issues/limitations of the kernel API versus the nice application-level lksctp-API. One thing that would make life a bit easier for the wrappers would be a nice input-output socket call. Currently we have misuse getsockopt().
From the application level something that is missing (this is SCTP specific) is a way to wait for free output buffers for a specific SCTP association in a one-to-many socket. The problem is that other associations may have free buffers, and poll() for POLLOUT will return immediately, but the association that the application wants to send to has its buffers full. = busy wait.
I am developing SCTP applications and has contributed to the linux implementation, and I think that one of the advantages of the socket API is that it is usable with select()/ and poll(), ie. it is file descriptors you can pass around.
But for SCTP there are things that don't fit nicely into the socket API, especially when using one-to-many socket types. For instance for retrieving options for an association you have to piggyback data in a getsockopt() call by using the output buffer also for input. It works, but it is not nice. Also, for sending/receiving messages you have to use sendmsg/recvmsg with all the features including control data, and the ugly control data parsing.
Does that OS rhyme with Polaris? It must have been version 2.6, which was notorious for interrupting system calls. Using SA_RESTART in sigaction() and calling fork1() (instead of the implicit abomination forkall()) solved a lot of issues for me.
But yes, your point stands.
I wouldn't loop for EBADF though because there is nothing safe you can do multithreaded programs.
> Ok, how about an example: Did you know that the close(2) can fail? What does this mean for real applications? Well you have to sit in a loop doing closes on a handle until it returns EBADF
No. You write a loop that terminates when close() succeeds.
Vmware Player is free. Vmware Workstation is not. But I doubt that for online courses that the extra funtionality in the workstation edition are needed.
Slashdot Mirror
Yes, he should select a phone with a poor antenna, and eat more cookies and sweets.
Have you actually tried blocking the signal with a Faraday cage?
At work, coworkers sometimes forget their mobile phone on their desks when going to lunch. If the phone rings then we do something about it, such as locking it into a heavy-duty transportation box, hiding it under their desk, etc.
Last time we put a coworker's iphone into a cookie tin (ok, the tin was not strictly a cookie tin but a flat tin can used for yummy Tunesian pastries, but I digress). The iphone lost signal. After the coworker came back and we had discussed Faraday cages we put the iphone into a different tin can (one used for Malaysian sweets) but it kept the signal. Puzzled, we tried with a different brand of mobile phone (HTC I believe) - it kept the signal inside both tin cans.
Conclusions:
- The iPhone antenna is worse than that particular HTC
- Blocking radio signals is hard.
The next experiment we are going to do will involve grounding the tin can. (preferably in a new tin box so we have a change to eat pastries again).
I had to switch to 802.11a because the 2.4GHz spectrum where I live is mostly saturated. I can see ~25 2.4GHz networks and at 2.4GHz I could get approximately 5-10Mbps throughput. In 5GHz I can get approximately 20Mbps throughput. The AP was more expensive but in addition to dual 2.4/5GHz mode I also got other "business" goodies such as VLAN, multiple SSID, decent documentation, PoE, etc.
I do see other 802.11a networks here (about 3) that apparently belong to the national telco.
Right now where I live: 1C and 97% relative humidity.
The important thing about humidity is that it is non-condensing (i.e. not raining) and that the temperature of the device is kept above the dew point (otherwise water condenses on and inside the device). So:
- dropping it in the bath tub: bad
- using it in fog: bad
- taking a cold device (eg. 5C) from the outside to the inside where the temperature is higher but relative humidity is also high: bad
I don't see how captive portals that rely on DNS tricks will work.
For those who don't know: A captive portal is used for directing you webbrowser to a specific page, eg. when you access a for-pay wireless network and it redirects you to a webpage where you can log in or sign up.
One mechanism is to capture the DNS query packet, and respond with, say, 192.168.0.1, where that server will respond with either a HTTP 301 redirect or the login-page. I cannot see how this will work with DNSSEC because the fake response will be be signed.
Another mechanism is to only redirect the HTTP request and respond with a 301 or login page. This should still work with DNSSEC.
So the big players, are probably a bit reluctant to enable DNSSEC on their domain because of the users that happen to sit behind the first type of captive portal.
I actually dislike the first mechanism, because even when it can be implemented nicely, many captives portals forget to set DNS response lifetime to 0 seconds so that when you have signed in/up, your DNS resolver will retry the query. Webbrowser reload only results in the you getting the login page again. So when connecting to a wifi network I don't know the details about I always first go to a webpage that I don't want to go to.
Obviously your boss' desk.
Amen to that.
I recently switched from 2.4GHz (802.11b/802.11g) to 5GHz (802.11a) for the same reason. Where I live I can see approximately 23 networks using 2.4GHz, and the real speed I get out of the 2.4GHz band is *maybe* 6Mbit/s. Full signal strength, but there is so much congestion in the band that the actual throughput is pathetic.
After I switched to 5GHz I get roughly 25Mbit/s consistently.
I didn't try 802.11n because my laptop + mac mini does not support that, and if the 2.4GHz band is that congested then it is not very likely that a more greedy approach to using the 2.4GHz band would have helped.
For that matter, how would a Linux user put it together? dd?
cat
There will always be a risk of information loss or small distortion of meaning, because languages are not equal.
Slang and sayings are probably the most difficult to translate. Eg. translating the English word "blue" to Italian will force you decide between "blu" and "azzurro" and either of those two choices insert extra meaning that wasn't in the original. Another example is the Danish saying "Træerne vokser ikke ind i himlen" which as far as I know has no direct equivalent in English.
My guess is that having the domains in that order allows you copy them directorly to/from DNS packets.
And the reason for the order in the DNS packets is that it allows compression by back-references. Roughly if a packet contains multiple names:
some.domain.example.com
other.domain.example.com
can be transmitted like:
some.domain.example.com
other<go back in packet at offset X>
See RFC 1035 section 4.1.4 for details.
So why do we seem to have teenage girls blossoming so early? I'd wager that it is the use of hormones in cows that has artificially accelerated the aging process among humans.
No, it is better nutrition and a resulting earlier increase of leptin production.
Plente of google results. Best hit seems to be "Human Reproductive Biology" by Jones/Lopez (google view of book)
No, I am not dissing linux. The linux system administration tools have caught up.
What keeps this SPARC space alive?
Solaris. ...)
Sun has maintained backward compatibility for applications for decades. You rarely encounter "oops, you need libc.2.0, but that is not supported on the newer kernels.". Also, the command-line system administration tools (especially for troubleshooting) are comprehensive (dtrace, truss, ptree, prstat, psrset,
Not if the cable is labelled "xyzzy"
Do you trust the labels on the cables?
If you are in the server room, and you have:
A: a spreadsheet that your predecessor made.
B: a post-it note on the switch saying it what it does.
Which one do you trust?
For the physical/low-level network the documentation should be in the network. Just like source code should contain comments about this particular piece of code, a similar approach works reasonably for the physical network. I see no point in a having an outdated spreadsheet. It is more useful that the cables and ports are labelled and numbered, that there is a post-it note on a switch say where the links go, etc.
The grand overview should be in electronic form, though. A scanned hand drawing is fine. A photo of a whiteboard drawing is fine too.
For the logical network put comments whereever possible. On settings, VLAN configurations, server connections, account setups, ...
Again, the grand overview should be in electronic form.
I have found it useful that the information is timestamped, so you know when it was last valid.
Thanks for that description. Quite interesting.
You mention flavors of BSD and signal handling. Perhaps http://lists.apple.com/archives/darwin-kernel/2005/Aug/msg00133.html may be helpful next time you encounter this. If OSX borrowed the signal handling code from the BSD relatives, it could be this. In that case it is probably a different bug on linux.
In any case an unkillable process is a kernel bug (as long as NFS and cluster software is not involved).
...a "timeout" parameter to the connect() call
There is a common wait to do this. I am not sure if it counts as a solution or a kludge:
- set socket into non-blocking mode
- call connect()
- check for immediate success (happens on solaris over loopback interface)
- if not:
- select/poll for writability, using a timeout
- When writable, retrieve connection status with getsockopt()
So yes, a timeout parameter to the connect() call would make life easier for client applications. But there is a workaround.
sometimes even a "kill -9" won't kill the process
That sounds odd. Which OS was that?
Do you happen to know of any uses of this protocol in real applications?
Diameter applications (rfc3588). SS7 can be transported over SCTP.
I have been in contact with people using SCTP for high-performance cluster computing, but I don't know the details.
There are experimental work on HTTP-over-SCTP. At one point it seemed that streaming applications could benefit from SCTP's lack of head-of-line blocking, but recently it seems that DCCP is a better fit for those applications.
True. Perhaps my viewpoint is a bit nonstandard because I also developed some of the wrappers in lksctp, and had to deal with some of the issues/limitations of the kernel API versus the nice application-level lksctp-API. One thing that would make life a bit easier for the wrappers would be a nice input-output socket call. Currently we have misuse getsockopt().
From the application level something that is missing (this is SCTP specific) is a way to wait for free output buffers for a specific SCTP association in a one-to-many socket. The problem is that other associations may have free buffers, and poll() for POLLOUT will return immediately, but the association that the application wants to send to has its buffers full. = busy wait.
I am developing SCTP applications and has contributed to the linux implementation, and I think that one of the advantages of the socket API is that it is usable with select()/ and poll(), ie. it is file descriptors you can pass around.
But for SCTP there are things that don't fit nicely into the socket API, especially when using one-to-many socket types. For instance for retrieving options for an association you have to piggyback data in a getsockopt() call by using the output buffer also for input. It works, but it is not nice. Also, for sending/receiving messages you have to use sendmsg/recvmsg with all the features including control data, and the ugly control data parsing.
They must have dropped the scene with the thermonuclear sharks.
I was looking forward to that.
Does that OS rhyme with Polaris? It must have been version 2.6, which was notorious for interrupting system calls. Using SA_RESTART in sigaction() and calling fork1() (instead of the implicit abomination forkall()) solved a lot of issues for me.
But yes, your point stands.
I wouldn't loop for EBADF though because there is nothing safe you can do multithreaded programs.
> Ok, how about an example: Did you know that the close(2) can fail? What does this mean for real applications? Well you have to sit in a loop doing closes on a handle until it returns EBADF
No. You write a loop that terminates when close() succeeds.
Vmware Player is free. Vmware Workstation is not. But I doubt that for online courses that the extra funtionality in the workstation edition are needed.