headers
Cool/Explosion | 1 Oct 2006 11:15

Re: Voyage-current - Console Interface

Hi Punky,
i was test voyage-current from 28.9.2006 and IMQ works well, bud 
IPtables haven't support for IMQ, and i must compiled new IPtables with 
imq patch...

Here is image of my version: 
http://85.132.161.242/voyage/download/voyage-custom/voyage-coolex.20060930-img.tar.gz
or bz2 file: 
http://85.132.161.242/voyage/download/voyage-custom/voyage-coolex.20060930.tar.gz
(i want copy it on alpha.voyage.hk but i haven't rights...)

Patch for IPtables is here: 
http://85.132.161.242/pool/imq/iptables-1.3.0-imq1.diff
BTW: this patch working on every version 1.3.xxx, i am using this patch 
on daily  snapshots...

Bye Cool...

Kim-man 'Punky' TSE wrote:
> Hi Cool,
>
> voyage.update (copyfiles.sh) should be fixed in the latest 
> voyage-current.
>
> Please try again, although I did not test it. ;-)
>
> Punky
>
> Cool/Explosion wrote:
>> Hi Punky,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edwin Whitelaw | 2 Oct 2006 16:03

Reported RSSI different on AP vs client/throughput problem

I have essentially identical WRAPs running Voyage 0.2.  Unit A has an 
SR5 (ath1) and CM9 (ath0), both in master mode.  This system has three 
client WRAPs, one a 5 mile (8000m) PtP link to Unit B and a PtMP link to 
two other clients (C & D) connecting to Unit A's SR5, each with SR5s of 
their own and a second Engenius as a local AP.  The A-C and A-D 
distances are 2.3 and 3.5 miles respectively

The PtMP link between A and C&D works fine with similarly reported RSSIs 
on both Master and client end.

Iperf between hh1 (Unit B) and the master (Unit A) will vary between 
<1mbs to well over 10mbs all while the signal strength remains fairly 
constant.  On occasion, the link will disappear long enough for ssh to 
drop but will work again within just a few seconds.

Iperf between A and either C or D is excellent with values typically 
just under 20mbs.

Unit B has a CM9 (ath1) and an Engenius NL2511MP Plus (wlan0).  The 
client consistently reports excellent signal strengths:

hh1:~# iwconfig ath1
ath1      IEEE 802.11a  ESSID:"buffalo-hh"
          Mode:Managed  Frequency:5.765 GHz  Access Point: 00:0B:6B:36:FE:21
          Bit Rate:24 Mb/s   Tx-Power=16 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:<key obscured>   Security mode:restricted
          Power Management:off
          Link Quality=39/94  Signal level=-56 dBm  Noise level=-95 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
(Continue reading)

Permalink | Reply | 2 comments |
headers
Angelo Compagnucci | 9 Oct 2006 18:41
Picon
Favicon

Voyage Linux toram

Hi to all!

It's possible to run voyage linux from ram as well DamnSmallLinux ???

Thanks !
Permalink | Reply | 0 comments |
headers
n schembr | 11 Oct 2006 17:22
Picon
Favicon

Flash drive failure

Ok, I know that usb flash dirves will fail in time.  However, how will they fail.  I've had  4 drives  fail in the
same  way,  failed read  from a block.   I think  the block  that  fails is part of the partition table.  The drive
just fails.  You can't unmount.  I have been able to use dd to wipe two of the drives and start over. 

what should I try to use to recover the usb flash drive?

If I switch to cf type II cards, will they fail in a better way?

Has any one had voyage fail during a rw session on Usb flash or cf II?

I've never had an issue with voyage on read only systems, but I've  only had  7 months of uptime. 

Nicholas A. Schembri
State College, PA USA
Permalink | Reply | 1 comment |
headers
Angelo Compagnucci | 11 Oct 2006 17:46
Picon
Favicon

Re: Flash drive failure

> what should I try to use to recover the usb flash drive?

I think you could use e2fsck -c /dev/xxx

Angelo
Permalink | Reply | 0 comments |
headers
Kevin Thackray | 12 Oct 2006 13:35

bootclean issue

Dear all,

I am setting few soekris with voyage 0.2, and I must say that voyage is one of the best distro I have tested for
this kind of babies!
However, I have 2 issues: 1 major (resolved) and 1 minor issue (dirtily resolved):
1) I am using the new wifi chipset from intel ipw2200 BG with WPA-PSK : I had issues to get WPA_PSK association
with the 0.2 voyage kernel (2.6.15) so I had to install a vanilla kernel (not patched) 2.6.18 and
everything is working fine, except that I do not have full natsemi watchdog support (not big deal)

2) Smaller issue: I am using wpa_supplicant with an, "pre-up" instruction in /etc/network/interface.
During boot sequence, the ifup init script is run, wpa_supplicant is the launched, and creates a socket
for the wpa_cli in /var/run/wpa_supplicant/. The issue is then, init script of mountnfs is called, which
sub-call bootclean.sh and thus deleting this socket :( My dirty workaround is to patch the bootclean.sh
script so that it does not remove this socket. Any ideas for a clean solution?

Kevin.
Permalink | Reply | 0 comments |
headers
Edwin Whitelaw | 12 Oct 2006 14:28

Re: Reported RSSI different on AP vs client/throughput problem

An update after further study on my part...

It appears that the RSSI on Unit A for the problematic link will drop by 
15db, from the low 60s, high 50s to the mid 70s and stay there for 
protracted periods of time (often many 10s of minutes but occasionally 
for only a minute or two) and then for no apparent reason will revert 
back to the excellent signal.  A colleague has suggested outside 
interference as a cause though, while plausible, that explanation begs 
the question as to why the other radio on the same unit sees no 
interference at all.  The two antennas are 2-3 ft apart, one above and 
one below the WRAP enclosure (~1.5ft coax) on a common pole.  The 
problem link is HPOL while the other is vertical polarity.  Current 
channel assignments are 153 (for the hpol link) and 149 for the other.  
I have tried any number of channels for the hpol link, including those 
in the 5.2 band with no change in behavior.   The angle between the two 
antennas is approx 52 degrees.

Note that the variation in signal between high and low is discreet, ie, 
when it's low, it varies only a db or two from around -74db and when in 
the good range, it is similarly consistent around -60db.  There are are 
very few, if any, intermediate values between the high and low.  The 
RSSI on the client end is _always_  good at approx -59db.

Signal strength variation was determined by running "iwconfig ath0" as a 
1 minute cron on a remote diskful machine to assure a persistent record 
in case of any reboot.

My next move is to replace the CM9 on the client end with the more 
powerful (?) SR5 and possibly the replace the master radio as well.  Can 
also rotate the antennas back to VPOL.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ron Wickersham | 12 Oct 2006 23:27
Favicon

Re: Reported RSSI different on AP vs client/throughput problem

we've seen cable problems act this way.  so you might be suspicious of
your pigtail and cable to the antenna.   and one lightning arrestor
had a similar action, although it was triggered by condensation in early
morning and repaired itself when the sun came around at the right angle
to warm it up.

-ron

--
/~\  The ASCII Ribbon Campaign
\ /    No HTML/RTF in email
 X     No Word docs in email
/ \  Respect for open standards

On Thu, 12 Oct 2006, Edwin Whitelaw wrote:

> An update after further study on my part...
>
> It appears that the RSSI on Unit A for the problematic link will drop by
> 15db, from the low 60s, high 50s to the mid 70s and stay there for
> protracted periods of time (often many 10s of minutes but occasionally
> for only a minute or two) and then for no apparent reason will revert
> back to the excellent signal.  A colleague has suggested outside
> interference as a cause though, while plausible, that explanation begs
> the question as to why the other radio on the same unit sees no
> interference at all.

---snip---
Permalink | Reply | 0 comments |
headers
Marek Andricik | 13 Oct 2006 12:39

debootstrap.voyage.sh on etch

Hi,

I'm having troubles installing voyage-current on etch host. It ends up
with the error message:

W: Failure while installing base packages.  This will be re-attempted up
to five times.
debootstrap error.  Exit code = 1.

Does not matter if I select DIST=sarge or DIST=etch (line 53-54 of
debootstrap.voyage.sh).

I tried the same on sarge host. Selecting DIST=etch ended like this:

E: No such script: /usr/lib/debootstrap/scripts/etch
debootstrap error.  Exit code = 1.

which is no surprise, while DIST=sarge went OK.

Stable voyage is quite old and I would like to have etch based voyage
with recent 2.6 kernel and working madwifi-ng drivers. Did I miss
something? Unfortunately, the Building Voyage from scratch page on
wiki is empty. 

Thank for any suggestions or pointers.

Marek
--

-- 
"You are hologram too?"
(Continue reading)

Permalink | Reply | 1 comment |
headers
mgrollman | 14 Oct 2006 02:39
Picon

Building the new linux-source-2.6.17-voyage_3.0-1


I would like to try building the Oct 8 kernel for 2.6.17 listed in:

http://www.voyage.hk/dists/experimental/linux/

I hope to use this with the most recent sarge vintage of voyage (is this 
a bad idea)?

Shown as filename: 

linux-source-2.6.17-voyage_3.0-1_all.deb 

I do not see a kernel config file on the voyage.hk site, and there does 
not appear to be on in this .deb file.  Do I need to download the full 
voyage-current to get a copy of the config for this kernel, or is there 
a smarter place to look?

Thanks,

- Michael
Permalink | Reply | 3 comments |

Gmane