Many EFNet IRC servers (though not all) already scan for open proxies (checking tcp ports 23, 8080, etc). However, not all do, and invariably you end up with a huge crapflood net on a single server (as was running around on EFNet a while back when they set their new max usercount record).
Unfortunately, there's not really much you can do about this. Some channels have bots that scan for open proxies when you join, but generally by the time this scan is complete the spam/crapflood has already taken place.
Also, not all of these are open proxies. You'd be amazed how many compromised windows hosts there are out there (what with code red 2 leaving cmd.exe laying around and all) that end up running proxies on oddball ports or even specially made IRC crapflood drones. Again, not much you can do about this (other than bitch out the sysadmin at the other end, who if they haven't noticed and corrected the situation by now probably doesn't care).
IP itself is a non-reliable protocol. My guess is that they're not actually doign IP on TCP on IP, but rather IP on IP, or IP on on IP. This way, you're only running one TCP and avoid the "meltdown" problem.
People tunnel IP in IP all the time. It can do ugly things to your routing tables (or it can make them neater), but it works just fine as long as you don't try and throw TCP in the middle. I've even tunneled TCP over IP over UDP over IP (IP in a UDP tunnel to a remote host). Again, no problem since there's only one "reliable" protocol in the mix.
If they are indeed doing IP over TCP over IP tunneling (with a TCP on the top for the final layer), then they could very well be in big trouble unless the underlying network (to the endpoint of that bottom tunnel) is reliable, which I don't believe 3G is.
StrongARMs are highly integrated chips. One piece gets you all sorts of stuff up to things like LCD controllers. They're not exactly upgradable and usually not a do-it-yourself project to build one from scratch.
However if you do still feel like building a StrongARM based machine from scratch (very difficult, I hope you're into board fabbing and have the gear to solder lots of exotic surface mount components), you might want to check out the LART.
If starting from something premade is OK with you, there's an excellent developer community for Linux on iPAQs at handhelds.org. The iPAQ has a huge expansion bus that you could probably use to do neat things with. Of course some hardware hacking would still be required. You can probably get one with a broken batt and/or screen off eBay pretty cheap.
Another option for a premade unit is the Lucent/Phillips IS2630 screenphone (Shannon). There's a project to run Linux on them called TuxScreen. Unfortunately they don't have any more of them for sale, but you might be able to find someone who bought more than one or who is done with theirs that's willing to sell you one. This is a pretty sweet phone, and there's lots of docs on modding it, but it's sure not a PC.
Enigmail menu in mozilla has an "Insert Public Key" option, and it will import them for you upon request when they have been inlined (which is all that menu option does).
A person would still have to know that people need their public key in order for anything to work, but the option to send it is there.
I think the idea was not that sysadmins don't know that physical security is important, but rather that they don't have direct control over the physical security of their systems sometimes.
If the local IT security guy/gal gets privilages on the physical security side, he/she can do a much better job of keeping the systems physically secure.
For all that switch cares, that router is another machine to speak with. Darn switch is just gunna forward it to where the MAC says to, pure and simple. If that be the router, it go to the router, if the server it be, there go ye (eh, so the rhyme is horrible, you get the picture).
A switch isolates collision domains, and only forwards packets to where they need to go (hence accomplishing the collision domain isolation). Basically, that means that the comps talking to the server (and sucking up mucho bandwidht doing so, as it's a full speed LAN connection not limited by the T1) won't interfere with the other peeps talking to the border router that's limited in speed by the T1.
This is the purpose of a switch (bridge), and it does this well.
Actually, a T1 is MORE than your average small school needs. The problem is all the idiots running P2P software and downloading warez all day long to their home directory. In terms of casual web browsing (especially in an educational environment, where cache hits tend to be frequent due to numerous students looking for the same info to complete an assignment), you can put hundreds or even thousands of simultaneous users on a T1. Web browsing is a very bursty activity; most of the time there's no traffic flowing over the line (while the person is reading the page).
I could have sworn BRI ran on a pair per B-Line with the D Line multiplexed across the lot of them (I know there's two pairs used in a standard 128k 2B-Line setup). You are right, this is standard "consumer" ISDN.
PRI is numerous B-Lines multiplexed using some method (I always thought it was TDMA? I'm not an ISDN wizard...). It is used to provide multiple phoen lines on a single copper pair or, recently in terms of telephone history, to move arbitrary data between two points at 1.544Mb/sec using the old T carrier systems (no need to modify it).
I assume you're talking about ethernet (which uses hubs).
Your T1 goes to your DSU/CSU, then to your Router, which probably has an ethernet jack on the back of it. Now, ethernet is 10 or 100Mbit, but since a T1 is only 1.544Mbit, 10 will do fine. Also, at a mere 1.544Mbit, the overhead of ethernet due to collisions is practically nonexistant, certainly not enough to affect the overall performance that you see in internet bound communications.
Now, if you're running bunches of local stuff over the same 10Mbit hubbed ethernet, you may see severe performance issues, and this would probably be solved quite nicely by a switch (as local traffic will be forwarded only locally, internet traffic will be forwarded only to the internet router).
PRI ISDN: Basically your consumer "BRI" (Basic Rate Interface) on Steroids: 24 B-Lines (I belive, or maybe 23 as you say) and a D-Line multiplexed onto a single pair of copper. This is your T1.
Point to Point: Kinda a generic term, but what you refer to (a pair of copper from you to your friend, usually with appropriate amplification for voice along the way) a Leased Line. These often have POTS modems run over them, or sometimes T carrier.
Frame Relay: Passing frames along until it either gets dropped or gets to it's destination. Most of the time the actual physical links in these networks are T carrier or ATM. Your description seems fairly accurate on this one, but I have little experience with Frame Relay, so I may be wrong.
T1s don't use hubs, or switches. They aren't ethernet.
As was mentioned in an earlier post, a T1 uses something called a DSU/CSU to manage the 24 BLines on your T1. This is sometimes built into a router, on a card in a router, or an external device running to some sort of high speed serial line (not always HSSI though) that can be linked to your router.
You can check the settings on this DSU/CSU to make sure you have a full T1 and not a fractional (all 24 channels is a full T1, less than 24 is fractional), but that won't help with finding oversubscription at the other end. There's really no easy way to check that, but if you never notice, who cares? Just make sure you get an SLA for the bandwidth you expect (usually the full 1.544Mb/sec on a T1) and if you at any time are unable to get that due to oversubscription by your ISP (all of them do it, some more than others though), you are entitled to compensation (often a partial refund or even being paid).
MTD devices (basically raw flash presented at the OS) usually end up with either CRAMFS (which is readonly) or jffs (usually v2) on it. JFFSv2 is journaling, and doesn't need to trash all over the place to fsck the drive.
Of course, this could be a concern on CF cards since, when used in an adapter, they show up as normal IDE hard drives. Obviously, you'd want to use a journaling filesystem like ReiserFS, JFS, Ext3, XFS, or <instert journaling filesystem of the day here>.
Most flash chips have a pin on them you can pull high to enforce write protect. All you should have to do is connect this up and you'll have a read-only card. Of course this may require some precision soldering as most flash chips are in very small formfactors...
The wearing out part is overestimated usually. I know that this is a concern sometimes for people using handhelds to do odd things (you'd be amazed what you can do with Linux on an iPaq), and someone was concerned about wearing out their flash.
Someone calculated that if you flash the flash in the iPaq as fast as possible, in a well distributed pattern (which CF cards do for you usually), it would take 12 YEARS to wear out a 32MB unit.
12 years is an awful long time. In 12 years your wimpy 512MB-2GB flash drive will look like NOTHING (think about the old 120MB hard drives, I had one of those in my comp 12 years ago and now they're totally worthless).
DVD-RAM has an extra plastic casing, which means that it is mechanically different from all the other standards, which are just a bare disc. The other standards are all the same size.
Flamebait...somehow that maked it even funnier than the first time I read it.
Honestly folks, I found that quite hilarious having used matchbox. It's definately one of the lighest window managers I've used.
--MonMotha
The people running Linux on the iPaq aren't your average PDA users. Many of them run it exactly because they can get semi-standard networking and can run standard apps. Have you ever played (well, played is an understatement sicne I could only see the top left corner) starcraft on your PDA? You can only do it via a remote display unless you've found a way to efficeiently emulate an 80386 on a StrongARM (and make it fast enough to run the game and still have time left over for the display and such).
Most people don't need X. There's OPIE/QTopia for people who wanta PDA. But for people who want to tinker or do rather odd thigns, X works pretty nicely, especially with this specially designed WM.
Actually, it looks quite a bit like WinCE or QTopia. The window control widgets are very small and unobtrusive. As another poster mentioned, they're also themeable should you not like the boring defaults.
Window control is a must in any multitasking OS. Even if the windows are modal, like they are in matchbox, you still have to have a way to close them and flip between them. The most efficient way I can think of to do this is a toolbar at the top. A hotkey would be another possibility, but there aren't very many buttons on the iPaq (though the Zaurus has a full keyboard).
Part of the reason for running X on these things is the fact that there's a HUGE amount of software instantly available. Remember, matchbox has modal windows for things other than dockables and dialogs. This elminates the problems with borders. When I ran FVWM I also turned my border width down to 2px.
Also, there are people who don't run X on handheld devices. The Zaurus for example runs QTopia, which draws to the framebuffer. An opensource, binary compatible clone is available under the name OPIE at http://opie.handhelds.org. However, it's not much different than running something like matchbox on X. There's also GPE, which the article mentions.
I used to run FVWM on my iPaq, and blackbox on occasion. They work, but due to the limited screen realestate, and also the orientation (3:4 instead of 4:3 aspect ratio), they tend to not work as well as one would expect. Then I tried matchbox, and I must say, Mallum has done a really good job.
I won't bore you with the details on how it works, you can read that in the article, but the way he has everything set up works very nicely. Modal windows are definately the way to go on such a small screen. Matchbox does this while still handling dialogs effectively.
I usually go for frequency and location of traffic accidents. It's fairly random (if you throw out locations that are common), and generation speed is VERY high.
Linux has rather impressive QoS facilities (so many options that it has an entire submenu in menuconfig). What you'll want is some floppy router distribution (mine's not quite ready yet, but I hear LRP has most of these options) and a decently powerful machine (100-200MHz pentium with 32-64MB should PLENTY for a DSL, but remember, you're not just routing/NATting).
There are tons of preconfigured things out there, but you might want to read up on tc (the traffic control manipulator, part of the iproute2 distribution), ip (from iproute2) and iptables (to help classify packets) before you dive in. The kernel ships with most of what you'll need (including the common CBQ scheduler), but there is a really cool scheduler known as HTB that is more accurate because it's resolution is traffic based, not time based. If you want to shape inbound traffic destined to teh router itself, you'll also need the IMQ patch.
Hope this helps. If you want more info, EFNet #iptables, look for KurD, the human router. He plays with this stuff all day at his job.
Slashdot Mirror
Many EFNet IRC servers (though not all) already scan for open proxies (checking tcp ports 23, 8080, etc). However, not all do, and invariably you end up with a huge crapflood net on a single server (as was running around on EFNet a while back when they set their new max usercount record).
Unfortunately, there's not really much you can do about this. Some channels have bots that scan for open proxies when you join, but generally by the time this scan is complete the spam/crapflood has already taken place.
Also, not all of these are open proxies. You'd be amazed how many compromised windows hosts there are out there (what with code red 2 leaving cmd.exe laying around and all) that end up running proxies on oddball ports or even specially made IRC crapflood drones. Again, not much you can do about this (other than bitch out the sysadmin at the other end, who if they haven't noticed and corrected the situation by now probably doesn't care).
IP itself is a non-reliable protocol. My guess is that they're not actually doign IP on TCP on IP, but rather IP on IP, or IP on on IP. This way, you're only running one TCP and avoid the "meltdown" problem.
People tunnel IP in IP all the time. It can do ugly things to your routing tables (or it can make them neater), but it works just fine as long as you don't try and throw TCP in the middle. I've even tunneled TCP over IP over UDP over IP (IP in a UDP tunnel to a remote host). Again, no problem since there's only one "reliable" protocol in the mix.
If they are indeed doing IP over TCP over IP tunneling (with a TCP on the top for the final layer), then they could very well be in big trouble unless the underlying network (to the endpoint of that bottom tunnel) is reliable, which I don't believe 3G is.
StrongARMs are highly integrated chips. One piece gets you all sorts of stuff up to things like LCD controllers. They're not exactly upgradable and usually not a do-it-yourself project to build one from scratch.
However if you do still feel like building a StrongARM based machine from scratch (very difficult, I hope you're into board fabbing and have the gear to solder lots of exotic surface mount components), you might want to check out the LART.
If starting from something premade is OK with you, there's an excellent developer community for Linux on iPAQs at handhelds.org. The iPAQ has a huge expansion bus that you could probably use to do neat things with. Of course some hardware hacking would still be required. You can probably get one with a broken batt and/or screen off eBay pretty cheap.
Another option for a premade unit is the Lucent/Phillips IS2630 screenphone (Shannon). There's a project to run Linux on them called TuxScreen. Unfortunately they don't have any more of them for sale, but you might be able to find someone who bought more than one or who is done with theirs that's willing to sell you one. This is a pretty sweet phone, and there's lots of docs on modding it, but it's sure not a PC.
Enigmail menu in mozilla has an "Insert Public Key" option, and it will import them for you upon request when they have been inlined (which is all that menu option does).
A person would still have to know that people need their public key in order for anything to work, but the option to send it is there.
Naw, that would be Xentronium.
:)
Yes, my new "Trusted Computing Platform" will be called "Xentronium" just to spite you! Bwahahah! I captured Orion before you!
For those that don't get the reference, play MOO2
I think the idea was not that sysadmins don't know that physical security is important, but rather that they don't have direct control over the physical security of their systems sometimes.
If the local IT security guy/gal gets privilages on the physical security side, he/she can do a much better job of keeping the systems physically secure.
Very odd, as the same page gives the following results for www.google.com:
Starting testing...
Stage one testing complete.
Stage two testing complete.
Testing complete for http://www.google.com. Result:
Reported as accessible in China
http://google.com inaccessable, but http://www.google.com accessable? What's going on here?
I know my friend's 128k ISDN BRI line (2x64kbit) is two pairs, making one pair PER B-Line...
PRI is more point-to-point than say, frame relay. A T1 (for example) can only be used to connect two pops, hence it's a point to another point.
Also, the T1 I worked with was only 1 pair I thought...
For all that switch cares, that router is another machine to speak with. Darn switch is just gunna forward it to where the MAC says to, pure and simple. If that be the router, it go to the router, if the server it be, there go ye (eh, so the rhyme is horrible, you get the picture).
A switch isolates collision domains, and only forwards packets to where they need to go (hence accomplishing the collision domain isolation). Basically, that means that the comps talking to the server (and sucking up mucho bandwidht doing so, as it's a full speed LAN connection not limited by the T1) won't interfere with the other peeps talking to the border router that's limited in speed by the T1.
This is the purpose of a switch (bridge), and it does this well.
Actually, a T1 is MORE than your average small school needs. The problem is all the idiots running P2P software and downloading warez all day long to their home directory. In terms of casual web browsing (especially in an educational environment, where cache hits tend to be frequent due to numerous students looking for the same info to complete an assignment), you can put hundreds or even thousands of simultaneous users on a T1. Web browsing is a very bursty activity; most of the time there's no traffic flowing over the line (while the person is reading the page).
I could have sworn BRI ran on a pair per B-Line with the D Line multiplexed across the lot of them (I know there's two pairs used in a standard 128k 2B-Line setup). You are right, this is standard "consumer" ISDN.
PRI is numerous B-Lines multiplexed using some method (I always thought it was TDMA? I'm not an ISDN wizard...). It is used to provide multiple phoen lines on a single copper pair or, recently in terms of telephone history, to move arbitrary data between two points at 1.544Mb/sec using the old T carrier systems (no need to modify it).
I assume you're talking about ethernet (which uses hubs).
Your T1 goes to your DSU/CSU, then to your Router, which probably has an ethernet jack on the back of it. Now, ethernet is 10 or 100Mbit, but since a T1 is only 1.544Mbit, 10 will do fine. Also, at a mere 1.544Mbit, the overhead of ethernet due to collisions is practically nonexistant, certainly not enough to affect the overall performance that you see in internet bound communications.
Now, if you're running bunches of local stuff over the same 10Mbit hubbed ethernet, you may see severe performance issues, and this would probably be solved quite nicely by a switch (as local traffic will be forwarded only locally, internet traffic will be forwarded only to the internet router).
PRI ISDN: Basically your consumer "BRI" (Basic Rate Interface) on Steroids: 24 B-Lines (I belive, or maybe 23 as you say) and a D-Line multiplexed onto a single pair of copper. This is your T1.
Point to Point: Kinda a generic term, but what you refer to (a pair of copper from you to your friend, usually with appropriate amplification for voice along the way) a Leased Line. These often have POTS modems run over them, or sometimes T carrier.
Frame Relay: Passing frames along until it either gets dropped or gets to it's destination. Most of the time the actual physical links in these networks are T carrier or ATM. Your description seems fairly accurate on this one, but I have little experience with Frame Relay, so I may be wrong.
T1s don't use hubs, or switches. They aren't ethernet.
As was mentioned in an earlier post, a T1 uses something called a DSU/CSU to manage the 24 BLines on your T1. This is sometimes built into a router, on a card in a router, or an external device running to some sort of high speed serial line (not always HSSI though) that can be linked to your router.
You can check the settings on this DSU/CSU to make sure you have a full T1 and not a fractional (all 24 channels is a full T1, less than 24 is fractional), but that won't help with finding oversubscription at the other end. There's really no easy way to check that, but if you never notice, who cares? Just make sure you get an SLA for the bandwidth you expect (usually the full 1.544Mb/sec on a T1) and if you at any time are unable to get that due to oversubscription by your ISP (all of them do it, some more than others though), you are entitled to compensation (often a partial refund or even being paid).
Hence why you use a journaling filesystem :)
MTD devices (basically raw flash presented at the OS) usually end up with either CRAMFS (which is readonly) or jffs (usually v2) on it. JFFSv2 is journaling, and doesn't need to trash all over the place to fsck the drive.
Of course, this could be a concern on CF cards since, when used in an adapter, they show up as normal IDE hard drives. Obviously, you'd want to use a journaling filesystem like ReiserFS, JFS, Ext3, XFS, or <instert journaling filesystem of the day here>.
So modify the card.
Most flash chips have a pin on them you can pull high to enforce write protect. All you should have to do is connect this up and you'll have a read-only card. Of course this may require some precision soldering as most flash chips are in very small formfactors...
The wearing out part is overestimated usually. I know that this is a concern sometimes for people using handhelds to do odd things (you'd be amazed what you can do with Linux on an iPaq), and someone was concerned about wearing out their flash.
Someone calculated that if you flash the flash in the iPaq as fast as possible, in a well distributed pattern (which CF cards do for you usually), it would take 12 YEARS to wear out a 32MB unit.
12 years is an awful long time. In 12 years your wimpy 512MB-2GB flash drive will look like NOTHING (think about the old 120MB hard drives, I had one of those in my comp 12 years ago and now they're totally worthless).
DVD-RAM has an extra plastic casing, which means that it is mechanically different from all the other standards, which are just a bare disc. The other standards are all the same size.
Or a RONJA system might be cheaper albeit a bit more difficult to build due to not being preassembled (or even in kit form), and a definate hack job.
Flamebait...somehow that maked it even funnier than the first time I read it. Honestly folks, I found that quite hilarious having used matchbox. It's definately one of the lighest window managers I've used. --MonMotha
The people running Linux on the iPaq aren't your average PDA users. Many of them run it exactly because they can get semi-standard networking and can run standard apps. Have you ever played (well, played is an understatement sicne I could only see the top left corner) starcraft on your PDA? You can only do it via a remote display unless you've found a way to efficeiently emulate an 80386 on a StrongARM (and make it fast enough to run the game and still have time left over for the display and such).
Most people don't need X. There's OPIE/QTopia for people who wanta PDA. But for people who want to tinker or do rather odd thigns, X works pretty nicely, especially with this specially designed WM.
--MonMotha
Actually, it looks quite a bit like WinCE or QTopia. The window control widgets are very small and unobtrusive. As another poster mentioned, they're also themeable should you not like the boring defaults.
Window control is a must in any multitasking OS. Even if the windows are modal, like they are in matchbox, you still have to have a way to close them and flip between them. The most efficient way I can think of to do this is a toolbar at the top. A hotkey would be another possibility, but there aren't very many buttons on the iPaq (though the Zaurus has a full keyboard).
--MonMotha
Part of the reason for running X on these things is the fact that there's a HUGE amount of software instantly available. Remember, matchbox has modal windows for things other than dockables and dialogs. This elminates the problems with borders. When I ran FVWM I also turned my border width down to 2px.
Also, there are people who don't run X on handheld devices. The Zaurus for example runs QTopia, which draws to the framebuffer. An opensource, binary compatible clone is available under the name OPIE at http://opie.handhelds.org. However, it's not much different than running something like matchbox on X. There's also GPE, which the article mentions.
--MonMotha
I used to run FVWM on my iPaq, and blackbox on occasion. They work, but due to the limited screen realestate, and also the orientation (3:4 instead of 4:3 aspect ratio), they tend to not work as well as one would expect. Then I tried matchbox, and I must say, Mallum has done a really good job.
I won't bore you with the details on how it works, you can read that in the article, but the way he has everything set up works very nicely. Modal windows are definately the way to go on such a small screen. Matchbox does this while still handling dialogs effectively.
--MonMotha
I usually go for frequency and location of traffic accidents. It's fairly random (if you throw out locations that are common), and generation speed is VERY high.
--MonMotha
Linux has rather impressive QoS facilities (so many options that it has an entire submenu in menuconfig). What you'll want is some floppy router distribution (mine's not quite ready yet, but I hear LRP has most of these options) and a decently powerful machine (100-200MHz pentium with 32-64MB should PLENTY for a DSL, but remember, you're not just routing/NATting).
There are tons of preconfigured things out there, but you might want to read up on tc (the traffic control manipulator, part of the iproute2 distribution), ip (from iproute2) and iptables (to help classify packets) before you dive in. The kernel ships with most of what you'll need (including the common CBQ scheduler), but there is a really cool scheduler known as HTB that is more accurate because it's resolution is traffic based, not time based. If you want to shape inbound traffic destined to teh router itself, you'll also need the IMQ patch.
Hope this helps. If you want more info, EFNet #iptables, look for KurD, the human router. He plays with this stuff all day at his job.
--MonMotha