mornin' all, i still haven't found the right solution for my situation, but after some digging, i realized that the free PuTTY SSH client (commonly used to access remote systems from under Windows) does NOT set the TOS bit in a way that would let the default wondershaper script identify its packets as high-priority. this means that -- as suggested by Ed -- prioritizing SSH packets in the uplink stream would have to be done on the basis of the port number used by these packets. also, because PuTTY does not set the TOS bit as wondershaper expects, PuTTY users will have to use *port-based* prioritization in wondershaper EVEN IF THEIR SSH SERVER RUNS ON THE DEFAULT PORT (22). i will post up my solution as soon as i get it working. in the meantime, please feel free to correct me if i'm wrong / suggest other solutions. peace -p -- Until lions have their historians, tales of the hunt shall always glorify the hunters. - African Proverb On Mon, 10-Jan-2005 at 22:16:02 +0000, Ed Wildgoose wrote: > Hi, > > >having read the docs and the wondershaper script itself, it occurred to > >me that the documentation promises an immediate drop in interactive app > >latency, specifically mentioning SSH as a big winner. > >however, looking through the script i can't really tell just *how* > >wondershaper figures out which port my SSH daemon is running on. > > > >so what i'd like to know is, if i'm running my sshd on, say, port 222, > >do i need to make any changes to the wondershaper script, or will it > >figure out the right number automagically (e.g. from /etc/services, > >where SSH is already correctly assigned to port 222) ? > >(conversely, does it 'need' to figure out this port number at all?) > > > > > > It's been a while since I looked through wondershaper, but the relevant > lines are apparently these: > > # TOS Minimum Delay (ssh, NOT scp) in 1:10: > > tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \ > match ip tos 0x10 0xff flowid 1:10 > > So it seems to be matching based on the "type of service" bits in the IP > packet. I seem to remember that SSH actually sets the IP tos bits > correctly? > > So it *should* work when ssh is on another port. I guess you need to > either tweak the script (if you want a quick fix then just mark anything > to/from port 222 as high priority), or else figure out why your packets > aren't matching the required rule.... > > Good luck > > Ed W
Attachment:
signature.asc
Description: Digital signature
