Greetings -
I''m new to QoS, so please be gentle (and yes, I''ve RTFM,
though I don''t
understand every bit of it)
Here''s the thing; I''ve tried several scripts--simple and
complex--for
classifying my Vonage traffic into a high-priority queue, but no matter what
I do it doesn''t seem to work. Right now I''m using the HTB
script I''ll
include below, which is a mashing together of several scripts I''ve
found
along with a lot of the LARTC HOWTO stuff. Bottom line; if I load up my
*outbound* connection and then try to make a Vonage call, my voice is so
chopped up at the other end that noone can understand me.
If it makes a difference, I *am* getting a few errors when I run this
script, but I''m a relative newbie to QoS so I''m not sure where
my errors
lie. I also thought that I might be having trouble with my MARKs in
IPTABLES, so I tossed in a line to filter based on IP DST/SRC instead of
relying on the marks (in a different, working IPTABLES script).
Any ideas?
Thanks.
--------- snip -----------------
#!/bin/sh
DOWNLINK="2800"
UPLINK="240"
DEV="eth0"
DEV2="eth1"
CEILING=$[100*$UPLINK/100]
MISC_RATE=$[90*$CEILING/100]
# Clean existing down and uplink qdiscs, hide errors
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
# Set packet queue much smaller than default (100):
ip link set dev $DEV2 qlen 10
## UPLINK ##
# Install root HTB; default traffic to 1:20
tc qdisc add dev $DEV root handle 1: htb r2q 1 default 20
# Shape everything at $CEILING speed - preventing huge queues in
# Cable modem which tend to destroy latency
tc class add dev $DEV parent 1: classid 1:1 htb rate ${CEILING}kbit
# Set up some branches for things
# 1:10 - High priority, interactive traffic, ICMP ECHO, TCP ACK
# 1:20 - Web, mail, standard stuff
# 1:30 - Everything else (Shareaza, etc.)
tc class add dev $DEV parent 1:1 classid 1:10 htb rate 128kbit ceil
${UPLINK}kbit prio 1
tc class add dev $DEV parent 1:1 classid 1:20 htb rate 64kbit ceil
${UPLINK}kbit prio 2
tc class add dev $DEV parent 1:1 classid 1:30 htb rate 64kbit ceil
${UPLINK}kbit prio 3
# All get Stochastic Fairness (except VOIP)
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10
## FILTERS ##
# VOIP traffic in 1:0 (i.e. skip the HTB entirely and drop it directly into
the interface queue)
# MARKS (FROM IPTABLES):
# VONAGE (1)
# SSH (2)
# WoW (3)
# TeamSpeak (4)
# Shareaza (20)
tc filter add dev $DEV parent 1:0 protocol ip prio 1 handle 1 fw flowid 1:0
tc filter add dev $DEV parent 1:0 protocol ip prio 2 handle 2 fw flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 3 handle 3 fw flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 4 handle 4 fw flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 50 handle 20 fw flowid
1:30
# TOS Minimum Delay (ssh, NOT scp) in 1:10, ICMP (impress the ladies), AH,
DNS
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip tos 0x10
0xff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 match ip protocol
1 0xff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 12 u32 match ip protocol
47 0xff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 13 u32 match ip protocol
50 0xff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 14 u32 match ip sport 53
0xffff flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 15 u32 match ip dport 53
0xffff flowid 1:10
# To speed up downloads while uploading, put ACKs in the interactive class
tc filter add dev $DEV parent 1: protocol ip prio 5 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# VOIP Test - If this works, then it appears that our MARKing in IPTABLES is
getting @#$@#$ somewhere
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip dst
192.168.1.110 flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip src
192.168.1.110 flowid 1:10
# Low-priority
tc filter add dev $DEV parent 1:0 protocol ip prio 40 u32 match ip dport 25
0xffff flowid 1:30
tc filter add dev $DEV parent 1:0 protocol ip prio 41 u32 match ip sport 25
0xffff flowid 1:30
tc filter add dev $DEV parent 1:0 protocol ip prio 42 u32 match ip sport 110
0xffff flowid 1:30
tc filter add dev $DEV parent 1:0 protocol ip prio 43 u32 match ip sport 143
0xffff flowid 1:30
#######################
## DOWNSTREAM CONFIG ##
#######################
# Ingress
tc qdisc add dev $DEV handle ffff: ingress
# VOIP
tc qdisc add dev $DEV parent ffff: protocol ip prio 90 handle 1 fw flowid :1
# Filter *everything* to it (0.0.0.0/0), drop whatever comes in too fast
tc filter add dev $DEV parent ffff: protocol ip prio 91 u32 match ip src \
0.0.0.0/0 police rate $[80*$DOWNLINK/100]kbit burst 10k drop flowid
:1
# "Shift" the priority map "down" so that we have higher
priority for VOIP
traffic. Even
# packets leaving the ethernet interface will give priority to VOIP traffic
(we hope).
# default priomap ---------------------------------------- 1 2 1 1 2 2 2 2 0
0 0 0 1 1 1 1
tc qdisc add dev $DEV2 root handle 1: prio bands 3 priomap 2 2 2 2 2 2 2 2 1
1 1 1 2 2 2 2
# Define the queues, without any kind of rate limiting
tc qdisc add dev $DEV2 parent 1:1 handle 10: pfifo
tc qdisc add dev $DEV2 parent 1:2 handle 20: sfq
tc qdisc add dev $DEV2 parent 1:3 handle 30: sfq
tc filter add dev $DEV2 parent 1: protocol ip prio 5 handle 1 fw flowid 1:1
tc filter add dev $DEV2 parent 1: protocol ip prio 21 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:2
tc filter add dev $DEV2 parent 1: protocol ip prio 44 u32 match ip dport 25
0xffff flowid 1:2
tc filter add dev $DEV2 parent 1: protocol ip prio 45 u32 match ip sport 25
0xffff flowid 1:2
tc filter add dev $DEV2 parent 1: protocol ip prio 99 handle 20 fw flowid
1:3
> Greetings - > > I''m new to QoS, so please be gentle (and yes, I''ve RTFM, though I > don''t understand every bit of it) > > Here''s the thing; I''ve tried several scripts--simple and complex-- > for classifying my Vonage traffic into a high-priority queue, but no > matter what I do it doesn''t seem to work. Right now I''m using the > HTB script I''ll include below, which is a mashing together of > several scripts I''ve found along with a lot of the LARTC HOWTO > stuff. Bottom line; if I load up my *outbound* connection and then > try to make a Vonage call, my voice is so chopped up at the other > end that noone can understand me. > > If it makes a difference, I *am* getting a few errors when I run > this script, but I''m a relative newbie to QoS so I''m not sure where > my errors lie. I also thought that I might be having trouble with > my MARKs in IPTABLES, so I tossed in a line to filter based on IP > DST/SRC instead of relying on the marks (in a different, working > IPTABLES script). > > Any ideas? > > Thanks. >It looks like you''re trying to send VoIP to the root class. Instead, create a separate high priority class just for VoIP (alongside of your ones for ssh etc) and instead of SFQ, attach a PFIFO queue. Also, shorten the lengths on queues for non-interactive traffic. Keep the VoIP PFIFO default length, and this will prevent the HTB from dropping VoIP packets when your other classes need to hand back bandwidth when you start a call. -Ron
There may be some other errors, but right up front it appears the sum of the rates of your child classes (1:10, 1:20, 1:30) are greater than the ceiling of your parent class (1:1). You need to divide them up based on the ceiling of 240kbit. for example: 1:10 112kbit 1:20 64kbit 1:30 64kbit Dan- Quoting Some Clown <systemic@comcast.net>:> Greetings - > > I''m new to QoS, so please be gentle (and yes, I''ve RTFM, though I don''t > understand every bit of it) > > Here''s the thing; I''ve tried several scripts--simple and complex--for > classifying my Vonage traffic into a high-priority queue, but no matter what > I do it doesn''t seem to work. Right now I''m using the HTB script I''ll > include below, which is a mashing together of several scripts I''ve found > along with a lot of the LARTC HOWTO stuff. Bottom line; if I load up my > *outbound* connection and then try to make a Vonage call, my voice is so > chopped up at the other end that noone can understand me. > > If it makes a difference, I *am* getting a few errors when I run this > script, but I''m a relative newbie to QoS so I''m not sure where my errors > lie. I also thought that I might be having trouble with my MARKs in > IPTABLES, so I tossed in a line to filter based on IP DST/SRC instead of > relying on the marks (in a different, working IPTABLES script). > > Any ideas? > > Thanks. >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> I''m new to QoS, so please be gentle (and yes, I''ve RTFM, though I > don''t understand every bit of it) > > Here''s the thing; I''ve tried several scripts--simple and complex--for > classifying my Vonage traffic into a high-priority queue, but no > matter what I do it doesn''t seem to work. Right now I''m using the HTB > script I''ll include below, which is a mashing together of several > scripts I''ve found along with a lot of the LARTC HOWTO stuff. Bottom > line; if I load up my *outbound* connection and then try to make a > Vonage call, my voice is so chopped up at the other end that noone can > understand me.Some others have pointed out a few errors, but can I just check whether it''s only uplink that gets choppy? Obviously first of all monitor your qdiscs to make sure traffic is being classified as expected, but after that do some testing on your VoIP app. I tested www.sipgate.co.uk on my PC based softphone and frequently got choppy sound for the first 30 secs of the call and then it settled down. Curiously changing to one of these hardware devices, a Budgettone in my case, and now the quality is perfect in both directions. No changes in qos settings between the two... Now, I haven''t debugged this further, but I think the actual voip settings in the device may help/hinder when there is congestion. Post some more info on your setup Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Some others have pointed out a few errors, but can I just check whether it''s only uplink that gets choppy? Obviously first of all monitor your qdiscs to make sure traffic is being classified as expected, but after that do some testing on your VoIP app. I tested www.sipgate.co.uk on my PC based softphone and frequently got choppy sound for the first 30 secs of the call and then it settled down. Curiously changing to one of these hardware devices, a Budgettone in my case, and now the quality is perfect in both directions. No changes in qos settings between the two... Now, I haven''t debugged this further, but I think the actual voip settings in the device may help/hinder when there is congestion. Post some more info on your setup ----------------------------------------------- Well, I''ve got a Vonage box (not the new Linksys-integrated ones; a Motorola) that is designed to be on the first device in the chain (Cable bridge, then Vonage, then switches/etc) and control its bandwidth needs that way. Of course, that messes up my whole world, because then I''m forced into double-natting hell because the Vonage box can''t do DHCP leases clamped to MAC addresses (as I have currently set up). Anywho... I have a Cable bridge (Comcast) coming into a Pentium II Xeon with dual NICs, out to a switch (no vlans or anything), and off of that is my Vonage box (among other things). No DMZ. My calls are only choppy on the outbound side, ostensibly because of the bandwidth disparity--I have 3Mb down, but only 256Kb up. When I''m not sending anything out, I''m good. When I load up the outbound however, I not only lose the ability to start a *new* ssh connection to my Linux box (Xeon), but all interactivity is destroyed (DNS lookups, etc) and my Vonage calls are worthless (though I can still hear the caller perfectly). I''m not discounting the possibility that my MARKs are getting stripped or otherwise re-mangled (so to say) in my excessively complex iptables script. Up until this attempt at learning QoS, I''ve never had a need for MARKs, so I''m going to sit down and work through my script on that end of things too. I am currently still getting a couple of errors, however, when I run the script (as posted), and I can''t figure out where they''re coming from: RTNETLINK answers: Invalid argument We have an error talking to the kernel RTNETLINK answers: Invalid argument We have an error talking to the kernel Unknown qdisc "protocol", hence option "ip" is unparsable RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists We have an error talking to the kernel RTNETLINK answers: File exists We have an error talking to the kernel But when I run a status check, something like tc -s qdisc, I get: qdisc htb 1: dev eth0 r2q 1 default 20 direct_packets_stat 0 Sent 7403 bytes 88 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 10: dev eth0 parent 1:10 limit 128p quantum 1514b perturb 10sec Sent 3127 bytes 11 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 20: dev eth0 parent 1:20 limit 128p quantum 1514b perturb 10sec Sent 928 bytes 15 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 30: dev eth0 parent 1:30 limit 128p quantum 1514b perturb 10sec Sent 3348 bytes 62 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc ingress ffff: dev eth0 ---------------- Sent 9741 bytes 108 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc prio 1: dev eth1 bands 3 priomap 2 2 2 2 2 2 2 2 1 1 1 1 2 2 2 2 Sent 862690224 bytes 3617955 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc pfifo 10: dev eth1 parent 1:1 limit 10p Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 20: dev eth1 parent 1:2 limit 128p quantum 1514b Sent 91437677 bytes 1647652 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 30: dev eth1 parent 1:3 limit 128p quantum 1514b Sent 771252547 bytes 1970303 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>My calls are only choppy on the outbound side, ostensibly because of the >bandwidth disparity--I have 3Mb down, but only 256Kb up. When I''m not >sending anything out, I''m good. When I load up the outbound however, I not >only lose the ability to start a *new* ssh connection to my Linux box >(Xeon), but all interactivity is destroyed (DNS lookups, etc) and my Vonage >calls are worthless (though I can still hear the caller perfectly). > >I''m not discounting the possibility that my MARKs are getting stripped or >otherwise re-mangled (so to say) in my excessively complex iptables script. >Up until this attempt at learning QoS, I''ve never had a need for MARKs, so >I''m going to sit down and work through my script on that end of things too. > >Debug this first. It''s not hard to sit and watch the byte counters scroll up. If any traffic goes to queues that you don''t expect then you know something is wrong. By the way, your other errors indicate that you don''t have the correct kernel modules loaded.... As I said though, my softphone on the PC kept going stuttery on the uplink even though QOS was working. (And only the uplink, downlink was perfect). With the hardware phone it''s perfect even when the link is under stress. I''m not sure exactly why, but I did notice that after a few mins the softphone usually got it''s act together so I suspect it''s a default delay thing which needs to get settled down to the level of jitter on the line.... Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-----Original Message----- From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Ed Wildgoose Sent: Wednesday, February 16, 2005 1:44 PM Debug this first. It''s not hard to sit and watch the byte counters scroll up. If any traffic goes to queues that you don''t expect then you know something is wrong. By the way, your other errors indicate that you don''t have the correct kernel modules loaded.... As I said though, my softphone on the PC kept going stuttery on the uplink even though QOS was working. (And only the uplink, downlink was perfect). With the hardware phone it''s perfect even when the link is under stress. I''m not sure exactly why, but I did notice that after a few mins the softphone usually got it''s act together so I suspect it''s a default delay thing which needs to get settled down to the level of jitter on the line.... -----Original Message----- Well, the byte counters seem to be doing what they should... When using a ''tc -s class show dev eth0'' over and over again <grin> I get appropriately increasing send/receive/lended/etc rates (I suppose). Still choppy, however. I tried one of these numbers: ''ip link set dev $DEV2 qlen 10'' in the script, having found that suggestion on a VOIP board somewhere, but nothing seems to have changed. I''ve tried many different queue scripts, some from others, some from my own addled mind, and none have worked. Most of the VOIP boards I''ve consulted have many, many messages from people who haven''t been able to get Vonage to play nice through any rational means. Explanations seem to vary from the tin-foil-hat crowd, to the lets-write-a-28-page-script folks. I''m very tempted to just go back to my Cisco gear for the QoS and leave this stuff be. The only last lucid--somewhat--thought that I had was that I might need to slow down my eth1 connection, which is to the switch, and hence all devices including my desktop--the one which hogs all bandwidth--because maybe the Vonage box can''t get through. Only trouble with that theory, though, is watching in Ethereal, the SIP packets come in with no delay... It''s the RTP stuff that gets hung up on the way out. As to the incorrect modules, I''m still working on that one. I upgraded this box from RH9.0 to a from-source 2.6.10 kernel, and for some reason (init scripts, to be sure) it doesn''t like to load any QoS modules on-the-fly; I have to dump ''em all in manually. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>I''m very >tempted to just go back to my Cisco gear for the QoS and leave this stuff >be. > >The only last lucid--somewhat--thought that I had was that I might need to >slow down my eth1 connection, which is to the switch, and hence all devices >including my desktop--the one which hogs all bandwidth--because maybe the >Vonage box can''t get through. Only trouble with that theory, though, is >watching in Ethereal, the SIP packets come in with no delay... It''s the RTP >stuff that gets hung up on the way out. > >I think you need to backup a bit and do some more debugging. You need to discover if your QOS is working or not on your data. If it is, then remember that you have full control of the outgoing connection so no queuing should ever occur if you don''t want it o. If your packets are being held up then change your packet marking so that they dont. You are going to have the same problems on your CISCO box I should think if it''s just a config problem. The other issue though is that you might genuinely be releasing packets too fast and getting queuing on your modem buffer. Try turning down the outlet speed quite a lot, say 50% and see how you get on. Debug that part first before turning it up again. Also try to turn on some kind of QOS bits with the vonage router so that it''s a little easier to mark your packets. Use something like ethereal or tcpdump to check that everything really is going to and from the addresses that you think it is. Please also trim your replies when sending to mailing lists... Good luck Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Le mercredi 16 février 2005 à 19:40 -0800, Some Clown a écrit :> > -----Original Message----- > From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On > Behalf Of Ed Wildgoose > Sent: Wednesday, February 16, 2005 1:44 PM > > Debug this first. It''s not hard to sit and watch the byte counters scroll > up. If any traffic goes to queues that you don''t expect then you know > something is wrong. > > By the way, your other errors indicate that you don''t have the correct > kernel modules loaded.... > > As I said though, my softphone on the PC kept going stuttery on the uplink > even though QOS was working. (And only the uplink, downlink was perfect). > With the hardware phone it''s perfect even when the link is under stress. > I''m not sure exactly why, but I did notice that after a few mins the > softphone usually got it''s act together so I suspect it''s a default delay > thing which needs to get settled down to the level of jitter on the line.... > -----Original Message----- > > Well, the byte counters seem to be doing what they should... When using a > ''tc -s class show dev eth0'' over and over again <grin>To have a real time graphical monitoring of your qdiscs/class without using tc -s class show dev eth0, you can try the last version of the qdisc monitoring tool at http://rawsoft.org _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Thursday 17 February 2005 15:19, vincent perrier wrote: <snip>> > > > Well, the byte counters seem to be doing what they should... When using a > > ''tc -s class show dev eth0'' over and over again <grin> > > To have a real time graphical monitoring of your qdiscs/class without > using tc -s class show dev eth0, you can try the last version of the > qdisc monitoring tool at http://rawsoft.orgAnother option is setup polltc[1] and let it grab the output from `tc` and graph it for your with RRDTool[2]. [1] http://edseek.com/~jasonb/code/polltc-1.02.tar.gz [2] http://ee-staff.ethz.ch/~oetiker/webtools/rrdtool/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> -----Original Message----- > From: lartc-admin@mailman.ds9a.nl > [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Ed Wildgoose > Sent: Thursday, February 17, 2005 6:08 AM > Subject: Re: [LARTC] VOIP Challenges... > > I think you need to backup a bit and do some more debugging. > You need to discover if your QOS is working or not on your > data. If it is, then remember that you have full control of > the outgoing connection so no queuing should ever occur if > you don''t want it o. If your packets are being held up then > change your packet marking so that they dont. > > The other issue though is that you might genuinely be > releasing packets too fast and getting queuing on your modem > buffer. Try turning down the outlet speed quite a lot, say > 50% and see how you get on. Debug that part first before > turning it up again.I''ve come to the conclusion that the following lines in my script are what causes my errors: # Ingress tc qdisc add dev $DEV handle ffff: ingress # VOIP tc qdisc add dev $DEV parent ffff: protocol ip prio 90 handle 1 fw flowid :1 # Filter *everything* to it (0.0.0.0/0), drop whatever comes in too fast tc filter add dev $DEV parent ffff: protocol ip prio 91 u32 match ip src \ 0.0.0.0/0 police rate $[80*$DOWNLINK/100]kbit burst 10k drop flowid :1 Seems to be on the Ingress filter... Now, I''m not sure that my problems will be magically solved when I fix this, but it''s one more step on the magical journey. So, to that end, does anyone have an idea why these lines wouldn''t work? I''m getting an error of: Unknown qdisc "protocol", hence option "ip" is unparsable If I re-run the script, then I get a whole lot of: RTNETLINK answers: File exists Along with a few: We have and error talking to the kernel But I''m sure that''s not a big deal, because after an initial boot and script-run, those errors aren''t present. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/