|
|
| Author |
Message |
| 21 new of 122 responses total. |
keesan
|
|
response 102 of 122:
| 
Dec 22 19:20 UTC 2006 |
There are lists of linux-compatible pcmcia cards. Why don't you search on
BSD PCI wireless?
|
ball
|
|
response 103 of 122:
|
Dec 22 23:06 UTC 2006 |
The man pages that I mentioned include lists of cards that
are supposed to work. Sadly some manufacturers will change
the chipset in a product without changing the model number
so it can be something of a lottery.
|
gull
|
|
response 104 of 122:
|
Dec 23 03:25 UTC 2006 |
Re resp:75: My impression is that the computer world pretty universally
used K=1,024 until marketing types realized they could put a bigger
number on hard disk packages if they used K=1000. For a while they
tried to avoid confusion (and presumably false advertising claims) by
using the phrase "million bytes" instead of "megabytes."
|
ball
|
|
response 105 of 122:
|
Dec 23 03:32 UTC 2006 |
I never saw them use K=1,000, but I did see them use
M=1,000,000 which makes sense in the context of S.I. They
could have excusably used k=1,000 but I never saw that
either.
|
ball
|
|
response 106 of 122:
|
Jan 20 01:51 UTC 2007 |
I now have a D-Link DWL-G510 802.11g PCI wireless network
adaptor working under NetBSD-current.
|
keesan
|
|
response 107 of 122:
|
Jan 20 02:00 UTC 2007 |
What module(s) and what else did you need to do?
|
ball
|
|
response 108 of 122:
|
Jan 20 03:07 UTC 2007 |
I didn't use any modules, but I had to upgrade to NetBSD 4
which is not quite released as stable yet (it's in Beta
testing). My kernel includes the ath(4) driver and for some
reason that I'm not clear about yet, bpf (the Berkeley
packet filter) was also required. I have to launch a thing
called wpa_supplicant because the wireless network uses WPA,
which is supposedly less insecure than WEP. The usual
procedure for launching the supplicant didn't work for me,
so as a temporary measure I launch it from the rc.local
script. Hopefully that will be fixed before 4.0 is released.
|
gull
|
|
response 109 of 122:
|
Jan 27 21:42 UTC 2007 |
It annoys me that some Linux distributions no longer have an rc.local
script. There are some applications where creating a full SYSV init
script is major overkill.
|
dtk
|
|
response 110 of 122:
|
Jan 7 03:28 UTC 2013 |
Do you include SATCOM in the list of wireless networking
techniques/technologies? When I deploy in the wake of natural disasters,
I am responsible for backhauling unclassified voice and data
communications over a satellite link, as well as management and
maintenance of the solution. -DTK
|
cross
|
|
response 111 of 122:
|
Jan 9 00:01 UTC 2013 |
Sure! Sounds reasonable to me.
|
dtk
|
|
response 112 of 122:
|
Jan 10 19:49 UTC 2013 |
Probably like a less cool version of the rig your brothers took out to
the mountains or the sandbox. -DTK
|
ball
|
|
response 113 of 122:
|
Jan 12 16:41 UTC 2013 |
Re. #110: That qualifies. Is that done using VoIP
or something else?
It's telling that even though years have passed
since I asked the question, adding a NetBSD host
to a WiFi network is still awkward to the point
where I tell people not to bother.
|
dtk
|
|
response 114 of 122:
|
Jan 12 17:58 UTC 2013 |
We use VoIP phones, connecting back to a phone switch at the HQ. The
phones use lightweight codec-specific signalling, common to both the
phones and the switch. Nothing terribly novel.
|
ball
|
|
response 115 of 122:
|
Jan 12 23:00 UTC 2013 |
Is latency much of an issue with the satellite link or is
that better with today's LEO birds?
|
dtk
|
|
response 116 of 122:
|
Jan 13 01:19 UTC 2013 |
We do not bounce off a LEO bird; they move too much. Instead, we bounce
off of a geostationary bird. We set expectations about latency, and
people adapt pretty quickly to the latency, as long as it is
consistent. Jitter is your big killer, not delay. Oh, and SAA on Cisco
gear, or SmokePing on UNIX (or Linux) is absolutely your friend,
followed closely by any NetFlow analyzer you can cope with.
|
ball
|
|
response 117 of 122:
|
Jan 13 01:58 UTC 2013 |
I'll ask the packet pushers what SmokePing is.
|
dtk
|
|
response 118 of 122:
|
Jan 13 13:44 UTC 2013 |
http://oss.oetiker.ch/smokeping/
|
cross
|
|
response 119 of 122:
|
Jan 20 02:02 UTC 2013 |
resp:115 Latency is almost always an issue for satcom. Pushing on Ka or X
band to geo-sync/geo-stationary is going to be slow because, well, the speed
of light isn't just a good idea, it's the law. :-)
I've never had great luck with LEO for anything. Maybe DAMA voice, but I
don't recall what birds those were bitting.
|
dtk
|
|
response 120 of 122:
|
Jan 25 22:06 UTC 2013 |
Here here. GEOS is great for resilience, and as long as you can tolerate
delay, you can go anywhere in its shadow. That said, it takes people a
while to get used to the delays involved in a voice call, but as long as
the delay is pretty consistent (i.e. low jitter), people adapt.
Oh, and for the fans following along at home, remember that the speed of
light in the atmosphere is a lot slower than the speed of light in a
vacuum.
I never tried using a LEO-provider; having to track a bird that is in
motion relative to your frame of reference either requires the dish to
be in constant motion, or accept drop-offs frequently. Neither seems
like much fun, and not worth the small improvement in round-trip-time.
-DTK
|
cross
|
|
response 121 of 122:
|
Feb 9 18:18 UTC 2013 |
Indeed. It's a pain in the butt.
|
tod
|
|
response 122 of 122:
|
Jan 27 15:08 UTC 2017 |
re #114
Back in the stone ages, we used analog phones through a multiplexer over
VHF. VOIP is a very specific protocol overhead for packet node sites.
I haven't looked at Network44 in years, though.
|