Tru64-FAQ-Network
Network 1 -- Why doesn't FTP work to an XYZ system?
Digital UNIX uses the IP type-of-service option (TOS) by default. This confuses some systems (reportedly Macintoshes). To turn off the option for ftp, create a file /etc/iptos with the following entries:
ftp-control tcp 0x0
ftp-data tcp 0x0
Reboot the Alpha system.
Network 2 -- How do you use a NFS-mounted /usr filesystem on Digital UNIX?
Setting Up A "Dataless" Environment under OSF/1 (2.X & 3.X) and a Comment on DEC's Dataless Management Services
ftp://s2k-ftp.cs.berkeley.edu/pub/personal/forrest/remote.mounting
Network 3 -- Where can I get rstatd for Digital UNIX?
rstatd is in /usr/sbin/rpc.rstatd
Network 4 -- How do I switch between the AUI and 10 Base-T Ethernet ports?
For the DEC n000 series of systems, the syntax is:
- Shutdown the system.
- At the ">>>" prompt, type:
set ethernet thick
or
set ethernet tenbt
- Reboot the system.
For the AlphaStation and AlphaServer systems, the syntax is different and depends on what Ethernet adapter you are using. For Digital EtherWorks adapters, they will automatically select between AUI and 10 Base-T but you may have to use the console command:
set EWA0_MODE AUI
to have this happen. Use the keyword TWISTED-PAIR if that's what you've got.
Network 5 -- Where can I get multicast software for Digital UNIX?
Information about software for multicast applications on Digital UNIX is available from:
http://s2k-ftp.cs.berkeley.edu:8000/sequoia/conferencing
or
ftp://s2k-ftp.CS.Berkeley.EDU/pub/sequoia/conferencing
Binaries of the MBone application suite are also available at:
ftp://chocolate.pa.dec.com/mbone
Network 6 -- What's wrong with xdr_long in the Digital UNIX XDR routines?
xdr_long is used for sending signed 32-bit values and cannot send 0xFFFFFFFF. xdr_ulong should be used instead. For 64-bit integer values, use xdr_hyper. See the manual pages for more details.
This is slightly misleading. xdr_long() can send -1, which in 32 bits is 0xffffffff. xdr_long() does range checking, insuring that the top 33 bits of its 64-bit argument are all ones or all zeroes. If this is not the case, then the signed long integer is beyond the range of representation within a signed 32-bit value, and xdr_long() rightly fails.
xdr_u_long() [note typo above!] insures that the top 32 bits of its 64-bit argument are all zero. If this is not the case, then the unsigned long integer is beyond ... blah blah.
So, the upshot is: If you're using signed values, use xdr_long(), and DON'T use unsigned constants like 0xffffffff to set variables. If you're using unsigned values, use xdr_u_long(). In both cases, make sure you're within range for 32-bits, if you want to interoperate with 32-bit machines using native data types.
Network 7 -- How do I configure the Berkeley Packet Filter and capture tcpdump traces?
1) Installing packet filter support tcpdump relies on a kernel option that ordinarily isn't enabled. You can fix this either by adding "options PACKETFILTER" to the system's configuration file and rebuilding (via doconfig -c
or by:
# doconfig *** KERNEL CONFIGURATION AND BUILD PROCEDURE ***
Enter a name for the kernel configuration file. [ALINGO]: FILTER
You want to name the configuration file 'FILTER'
Is that correct? (y/n) [y]: y
*** KERNEL OPTION SELECTION ***
Selection Kernel Option
-----------------------------------------------
1 System V Devices
2 Logical Volume Manager (LVM)
3 Kernel Breakpoint Debugger (KDEBUG)
4 Packetfilter driver (PACKETFILTER)
5 STREAMS pckt module (PCKT)
6 Data Link Bridge (DLPI V2.0 Service Class 1)
7 X/Open Transport Interface (XTISO, TIMOD, TIRDWR)
8 File on File File System (FFM)
9 ISO 9660 Compact Disc File System (CDFS)
10 Audit Subsystem
11 Local Area Transport Support
12 All of the above
13 None of the above
-----------------------------------------------
Enter the selection number for each kernel option you want.
For example, 1 3 : 4
You selected the following kernel options:
Packetfilter driver (PACKETFILTER)
Is that correct? (y/n) [y]: y
... Rebuild and boot the new kernel.
2) Create the packetfilter devices:
# cd /dev
# ./MAKEDEV pfilt
MAKEDEV: special file(s) for pfilt:
pfilt0 pfilt1 pfilt2 pfilt3 pfilt4 pfilt5 pfilt6 ... pfilt63
3) Get a better tcpdump (pre V4.0 systems only) Email me for a compressed, uuencoded file of a tcpdump that decodes NFS V3 and several other Sun RPC protocols (MOUNT, NIS, NLM, PORTMAP, and STATMON).
4) Enable local copy promiscuous mode
# pfconfig +p +c ln0 (or tu0 or whatever)
5) Run tcpdump. Please read the man pages before doing serious monitoring! To look at some NFS traffic, try:
# tcpdump -s300 -c100 -Nt udp port 2049 [to look at all NFS traffic]
# tcpdump -s300 -c100 -Nt host foo [to look at all to/from foo]
-s300 "snaps" up the first 300 bytes of each message, generally enough to get lower level headers, RPC, and enough NFS protocol to make sense of the requests. -c100 says to capture 100 messages and exit. -N says to suppress the domain name (e.g. .zk3.dec.com) in hostnames. -t says to suppress printing timestamps. The result is usually still too long for a 80 column screen, I keep a wide xterm lying around for most of my tcpdump monitoring. The -m option splits some messages over multiple lines.
If you send people traces, I generally recommend that you capture data to a binary file and send that. If the recipient needs to, he can run tcpdump with extra filtering or -x (hex dump) to really dig into problems. Do something like:
# tcpdump -w /usr/tmp/foo.dmp -s300 udp port 2049
tcpdump: listening on ln0
Using kernel BPF filter
^C
1040 packets
# compress foo.dmp
# uuencode foo.dmp.Z < foo.dmp.Z > foo.uu
Capturing to a file bypasses all the decoding code which can be very slow and can generate its own IP traffic (e.g. resolving host names).
Network 8 -- How do I switch to full duplex 100mb?
Auto negotiation with hubs is frequently unreliable. The problems usually manifest themselves as slow/poor network response. I have seen actual file transfer speeds that were far worse than the 100mb/s that should have been negotiated. Look at the switch/hub port configurations. Sometimes it actually negotiates down to 10mb! If you set 100mb/fdx, be sure to hard set it on the host AND switch/hub.
If you experience poor response, on what appears to be a clean network, auto negotiation problems are a good possibility to check into.
To hard set 100mb/fdx at the console level:
AlphaStation and AlphaServer console:
Shutdown the system
>>> set EWA0_MODE FastFD
Reboot the server
It will be set each time the system boots.
To hard set 100mb/fdx at the OS level:
The ifconfig speed flag determines the speed (regular or fast Ethernet) and half- or full-duplex mode operation on the tu interface when that interface is using the twisted-pair port as follows:
Value Configuration
-------------------------------------
10 10 Mbps Ethernet half-duplex
20 10 Mbps Ethernet full-duplex
100 100 Mbps Ethernet half-duplex
200 100 Mbps Ethernet full-duplex
-------------------------------------
After the interface is online, you can use the ifconfig up and down options to change the speed value dynamically. Stop adapter transmission with down and set the speed in the same command line. Then specify up without a speed value to restart the adapter.
Example:
ifconfig tu0 down speed 200
ifconfig tu0 up
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
