Troubleshooting your connection to Optus@Home

You're probably here because the last page didn't work for you.

October 23rd 2001: This page has also been updated to reflect the new connection process.
The co-30XXXXXX-a Client ID string is now redundant. The scripts and string references that were here have been removed or should have been :-)

• Introduction
• What should happen?
  
• What can Linux tell me?
  
• What can Windows tell me?
  
• If you couldn't get to first base then maybe...
  
• You can connect but it's not working fully
• Connection dies after a (day|week|variable) time
  
• No connection after rebooting
  
• No connection at all
  
• Your NIC isn't behaving
  
• Some Highlights -- of a few relevant points
• Floppy test image -- when you don't know what to trust anymore
• Is a second opinion required?
  

When it all gets too much and you're going in circles then go for a walk (further than the microwave) or play ball with the pet. Just get away from it for a while - you may find yourself doing a Homer when you get back.

As before -- italics are directories and bold are commands (where appropriate). File structure is based from RedHat, files and locations may vary for other distro's - read the doc's and modify as appropriate.

I've tried to keep away from proprietary tools (Yast, Drake etc). It's not a statement about there usability but an obvious need to keep to the basic tools, which should be included or at least available for all distro's.

Nov 11 15:10:29 graybeard dhcpcd[1987]: broadcasting DHCP_DISCOVER
Nov 11 15:10:29 graybeard dhcpcd[1987]: DHCP_OFFER received from (203.164.2.55)
Nov 11 15:10:29 graybeard dhcpcd[1987]: broadcasting DHCP_REQUEST for 203.164.18.163
Nov 11 15:10:29 graybeard dhcpcd[1987]: DHCP_ACK received from (203.164.2.55)

Use  /sbin/dhcpcd -k to kill the process if needed.

Nov 11 15:10:42 graybeard dhcpcd[1988]: sending DHCP_RELEASE for 203.164.18.163 to 203.164.2.55
Nov 11 15:10:42 graybeard dhcpcd[1988]: terminating on signal 1

If your log doesn't show anything (/var/log/messages) you may need to tell syslog to be a bit more vocal.

We'll go overboard and tell it to log everything to terminal 11.
Open /etc/syslog.conf  and add   *.*        /dev/tty11   save it and then /etc/rc.d/syslog restart to reread the config file. Change to the terminal by Alt F11 or if you're within a GUI then using Ctrl-Alt F11 should drop you back to the console.
You now should see at least the syslog/klog daemon restart messages on the screen.
Go back to your other screen and enter the /sbin/dhcpcd............... command and see what eventuates.

Remember to reinstate syslog when you've finished - unless you like it that way of course.   Be aware that *.* logs everything, failed password attempts will be shown in clear text, so at least reinstate the ;authpriv.none if you want to keep the redirection.

If you feel the above redirection of syslog is overkill then run tail as described below.

• man - it can't be stressed enough. Reading help files is usually our last resort but there is a wealth of information there so man <whatever command you want > will be enlightening.
• ping XXX.XXX.XXX.XXX to check for active connections - an indispensable command. Ctrl C to kill the output or use the -c switch -- man ping for the good oil.
  
• traceroute Use it as appropriate.
• tcpdump -i eth0 will output tcp traffic on interface eth0 to the console.
  
• tail -f /var/log/messages will continuously output the contents of the log file messages to the console, you should see the conversation between yourself and the DHCP server at optus (along with a lot of other traffic) Ctrl C will kill it.
  
• debug switch -d
  /sbin/dhcpcd -d eth0 the -d option will increase the logging facility for dhcpcd -- use it with the above logging command.
  
• Checkout /etc/dhcpc/dhcpcd-eth0.info when the connection works or perhaps as a check between attempts. It's not a "need to know" but it's contents should contain some meaningful information. It's creation also tells a story ( mv /etc/dhcpc/dhcpcd-eth0.info /etc/dhcpc/dhcpcd-eth0.info.last to guarantee a fresh file)
• ifconfig at the command line will give you detailed information about your interfaces.
• netstat -atp will list your active TCP connections.
• route will show your routing table - how each interface is configured and gateways to networks. Default is via the cable modem.

• winipcfg for Win 95 - Win 98 or ipconfig for Win 2k
  Start ==> Run then type in Winipcfg. This will give you information about your existing IP configuration. Use it while you're connected to optus (via windows) for an overview of the existing settings.
• If for some reason winipcfg fails, a right click on the Network Neighborhood icon then Properties will reveal a tabbed window with networking information.
• From within a Dos shell
  
  • netstat -an to show active connections.
  • ping As for Linux - it has slightly different options.
  • tracert for traceroute.
  • route print will get the routing table.

• You need to be root.
  If you are within a user shell, going to root via su and "bash: dhcpcd: command not found" keeps popping up, then you need to specify the full path /sbin/dhcpcd in this case and use su - to get a full shell. Check the difference with echo $PATH from within each shell, try and read root's mail. See man su for slightly more detail
• Mention was made about not editing a text file for Unix/Linux under dos. If there are strange messages such as the above "command not found" that really don't seem to make sense, then this may be the cause.
  To terminate a line Linux uses LF (linefeed) only, Dos uses CR LF (Carriage-return linefeed). You risk seriously confusing your Linux box as well as yourself, so DON'T. Unless you want to use Vim for win32 or PFE
  
• Again - If absolutely nothing is working, check the server status page from your existing connection. There is every (unlucky) chance that optus's servers HAVE fallen over or they are doing work on the DHCP servers. I mean with the luck you've been having why not that as well :-(
  If that link came up with an error then the "www" needs to be substituted with your domain name. See below. If you're outside the optushome network (using your old dial up account or viewing from elsewhere) then it will never work - it's an internal link.
  
• Are you using RedHat 6.1? The 6.2 rpm has been used to solve connection problems on this release. YMMV

• You can set the -R flag to prevent dhcpcd from clobbering the /etc/resolv.conf file, include it if desired - but you must have valid nameserver entries in /etc/resolv.conf to be able to access the Internet. If you wanted to use nameservers other than the Optus ones you'd do this, most users won't need to change the default behaviour man dhcpcd
• If you ping -c 5 203.108.7.77 from a working connection you will get a response back, this suggests a ping -c 5 www.ozemail.com.au should also work, being the exact same address. If the dotted quads work but the resolved names don't then /etc/resolv.conf is not populated (see -R directly above) or your name resolution isn't working as it should - or you need to find some valid address 'cause ozemail has fallen over ;-)
• You type www, or mail etc and nothing happens.
  You need to set the domain in /etc/resolv.conf. This should be done automatically by the dhcpcd daemon, but if you're on a networked computer running (perhaps) win95 (98) then a right click on the Network Neighbourhood icon then ==> Properties ==> TCP/IP ==> Properties ==> DNS Configuration ==> enable DNS --> Domain. In this window you'll insert your domain. What is it ? look in /etc/dhcpc/dhcpcd-eth0.info on the RedHat box. Your mail header or newsgroup posting will have it also. It will be the form of (example only) vic.optushome.com.au
  If it still plays up then "hardcode" it into the address's eg:- www.vic.optushome.com.au
  

• Is networking set to start?
  Be certain that networking is configured to start at boot time.
  This can be checked from the command line by using the command chkconfig.
  If you run chkconfig --list network then you should get something like...

  network      0:off   1:off   2:on   3:on   4:on   5:on   6:off
  

  What you are looking for here is an on at your default boot level usually 5:on for the GUI start or 3:on for the terminals.
  chkconfig --add network
  will enable networking if all is not well

  If the network was off and you do the chkconfig --add network, but then a dutiful chkconfig --list network still says they are turned off, don't despair.

  #! /bin/bash
  #
  # network       Bring up/down networking
  #
  # chkconfig: - 10 90
  # description: Activates/Deactivates all network interfaces configured to \
  #              start at boot time.
  # probe: true
  
  

  Where that "-" is in the string "# chkconfig: - 10 90" will need to be replaced with the appropriate run levels.   If you were to use linuxconf or one of the automated tools these fields would be filled in for you. Because we're not we'll do it manually. 345 should suffice in most cases - do some research for the correct levels :-) cough .....man chkconfig.
  It will now look like this "# chkconfig: 2345 10 90" the 10 and 90 may be different for your distro. - don't change them.  Now turn the service off first; you and I know that it's already off but we'll humour the computer; having issued chkconfig --del network ( turning it off via the software ) a subsequent add should set it up correctly. You then need to turn it on as outlined directly below.
  
• You can run this command at anytime.
  Try /etc/init.d/network and you'll be given a list of options, pick the appropriate one and see what happens. The file may be in /etc/rc.d/init.d depending on the Linux flavour.

• Reset the modem
  If you're at a loss, then resetting the modem may help. Turn it off and then on to cycle it through it's configuration routine, the theory is this will force the modem to reread the MAC address of your NIC.   I'll add that at least for me this hasn't always been necessary, I've swapped cards and ifup'd without any hiccups but that's probably because they were nearly identical cards (MAC numbers). As usual YMMV so don't ignore the step if all else fails. In fact ....
  
  1. DON'T ignore this step -- especially if you're using a different card (different MAC address).
     
  2. DO turn it off at the wall - forget all other buttons
     
  3. DO have the NIC powered up (computer booted up) while resetting the modem. The modem needs to query the NIC for its MAC address, this cannot happen without the NIC being powered up.
     
• You may have firewalled yourself out.
  When the dhcpcd client trys to connect on boot up the firewall is not active and so shouldn't be an issue.  As we need to be transparent to the optus server to obtain and renew the lease and if we are in the middle of an existing session a firewall may be causing our request not to be heard.
  
  • If you don't know what a firewall is then you need to find out soon.
    If you can't renew the lease, symptoms are that your connection dies after X time period, then the firewall is the likely culprit

    Run ipchains -L -n and this will dump your current firewall to the screen. If you get more than

    Chain input (policy ACCEPT):
    Chain forward (policy ACCEPT):
    Chain output (policy ACCEPT):
    

    or there are DENY, REJECT policies in the output, then you have one running and the following rules need to be in it.

  • ---

       ipchains -A input -l -i eth0 -p udp -s $DHCPSIADDR 67 -d $IPADDR 68 -j ACCEPT
       ipchains -A output -l -i eth0 -p udp -s $IPADDR 68 -d $DHCPSIADDR 67 -j ACCEPT
    
  The server runs on port 67 (that's optus) and the client on port 68 (that's you). So input from 67 to 68 and output from 68 to 67 is needed.
  $IPADDR is your external address (in my case it's 203.164.18.163 )and $DHCPSIADDR (203.164.2.55 for mine ) is the optus server. Because it's a chicken or egg situation, these may need to be 0/0 until you get a connection, you can then change them to there assigned values by looking in /etc/dhcpc/dhcpcd-eth0.info after a successful connection.

  If you trust the internet at large then you can use 0/0 permanently. I don't so I lock the dhcp server down to a known address, thus the $DHCPSIADDR variable. In 18(?) months it's only caught me out once when they changed dhcp servers, a check of the growing message log for the new servers IP and a quick edit solved that problem

The following may involve hardware changes. Be sure that you're comfortable with what you're doing, and can accept the consequences.

• If you're using the Optus NIC, you're on your own. ( As of jan 2002 this issue seems to have died out, but read on just in case )
  By all means try the NIC (I did and it didn't) but if you're having real trouble with the connection then you'll need to eliminate the NIC from the puzzle at some point.
  The easiest way is to beg, borrow or buy *gulp* another NIC to see if you then get a working connection. Chances are you will, but if you have to buy one then make sure it's your last resort :-)
  Some get it to work others don't so YMMV. If you do get it going then let us know, if enough people get it working I can stop scaring the new punters. This still ( sept 2001 ) causes problems at times.
  There has been success with the SMC 1211TX(Ezcard) using the rtl8139 driver.
  The ISA, SMC 8416 is a goer as well.
  Any others? I'm only an email away...
• Is the card working?
  
  • Don't forget the led's on the NIC. ping the interface IP (give it a static one as a temporary measure) and check to see if the card responds.
    
  • If the above is okay check that it's talking to the correct socket (see below).
    
  • For older cards - there may be a problem with sharing interrupts which will require the card to be reconfigured via jumpers or a vendor supplied program. ( With RedHat, on bootup there should have been an OK after the ethX's , and everyone of them too.)
    Don't have this driver disc? A search of the net or through the Linux kernel documents(?) will find the config program or clues. The vendor one will run from a native dos shell (just format a system boot floppy under windows, unzip the driver file and reboot the computer so that it starts from the floppy).
    Follow the prompts, read the documents. This will allow you to set interrupts, memory allocations etc.
    
  • Don't know what card it is?
    If the card has been detected by the system ifconfig should show the MAC address, HWaddr XX:XX:XX:XX:XX:XX It may also be screen printed on the board. The first three pairs can then be checked against the file /var/arpwatch/ethercodes.dat for a match. Armed with the Manufacturers name you may find the drivers at WinFiles.com which will should give you some info. and the configure program.
  • Last step didn't work? then search the net for the chip numbers - or get another card :-)
  • Primarily for ISA cards - the main BIOS may need to be configured to reserve an interrupt for the card. Check your manual and reread the "red" above. Remember what you do so you can (hopefully) reverse it!
    
• If you have two cards - pull one out for the time being. When trouble-shooting minimize the possibilities it can save a lot of duplicated or wasted effort.
  
• For some older cards - It maybe that you've got two cards, and they both work because you've checked them on the internal LAN.
  CAUTION - Are you swapping between 10base2 and 10baseT for the internal, external networks? Be aware that some cards may need jumpers reset or the config program run to allow the use of the other socket. Yes the cards work but are talking on the wrong interface when matched to the TP (modem) cable. Not all cards auto select, check the documents or run the previously mentioned config program
  The lights blink on the correct card but the bit's are falling on the floor - traffic's going to the wrong socket!
  
• Two PCI cards -- The order of the PCI cards on the bus will determine their interface number. Try swapping PCI slots to match them up with the correct ethX number.

This all a repeat of the above but highlights some of the possible reasons that a "good" card may not work as it should

1. i If you're migrating your setup, from one computer to another, then use the same cable to connect between the machine and modem. (just to make sure we are using a known working cable that is of the correct configuration - normal or straight through)
2. Connect the cable directly between the modem and computer, don't use a hub or switch in between ( later you may be able to but for the moment we'll keep it simple.)
3. If the NIC is different to that in the existing machine then power off the modem, pause for a sip of coffee, then power on the modem (the computer with the troublesome NIC needs to be booted up for this query to return a valid result). The modem lights (CM100) should run through the self check sequence before settling down to the usual displayed pattern. This should enable the Optus servers to give you a new lease (by deregistering the MAC address from the modems internal registers?)
   Thats power off at the wall, don't trust any of the buttons on the front, side or wherever.
4. If you're able to, move the working NIC from the machine that connects and use that one in place of the one that is being difficult. (This should now eliminate the NIC and cable from the list of potential problems.)
5. The state of the firewall is a possible problem - especially with newer distributions that attempt to assist the process by offering secure, medium, minimal (whatever) during setup, so we need the output of ...
6. ipchains -L -n     to be sure that the firewall is open for lease renewal ( ports 67 and 68 ) If there are doubts about the rules output by that command then
   ipchains -F input && ipchains -P input ACCEPT
   ipchains -F output && ipchains -P output ACCEPT
   ipchains -F forward && ipchains -P forward ACCEPT
   will flush the existing firewall rules and change the default policy to ACCEPT allowing ALL traffic to pass through the firewall.
   The above is a security risk and is only used for testing purposes, a policy change with additional rules must be put in place when connected normally.
   

• This LRP image is a partially configured Dachstein image, for the desperate or unafraid.
  The intention is that by using a known and working configuration, that is independent of your existing setup, then the card and cable that make up eth0's connection to the internet can be proven to work or not, hopefully isolating the problem.
• This image has been configured with NO firewall so everything internal is open to the world and therefore it's NOT suitable for a normal connection (although it can be configured to be a useful alternative.) It's therefore recommended that you disconnect the cable from the internal network (eth1) while using this image, even though the internal card has not been setup by me, depending on the modules used and default IP it "may" be configured inadvertently. (highly unlikely)
  If you don't have a second card then it's even less of a problem :-)
• Because it loads from floppy and resides in memory no changes are made to your existing windows, linux, bsd, dos etc setup.
• This image can be used on any machine that you can configure the NIC for.
• login - root    password - there is none!
• You'll need to know what the module is that your NIC uses and edit /etc/modules to load it from /lib/modules/ on bootup.  If you get the module right and the card is configured at boot then everything should work.  A valid lease should be visible from the login prompt by paging up once or twice (shift + pageup)
• Because it has no firewall you should be able to ping www.ozemail.com.au and get a reply - from any site that normally responds in fact.
• • if it doesn't then the odds are high that the problem being experienced is hardware related as in:- NIC{interface type wrong, problem of card}, cable, modem{reset needed?}, server{down}, or ......{if we new we wouldn't be doing this ;-)}
    
  • If it does then it would suggest that the software {config} is the culprit with your distribution.
    
• To set up, or understand the Dachstein distribution while not exactly a No-brainer, it shouldn't be too difficult. The biggest hurdle is understanding the module system and which one your card uses
  
• It's assumed that you'll use this method as a last resort. To assist with configuring the image the readme.txt would be the starting point, this file will also be on the floppy.
  
• To transfer the image to disk..
  
  • insert a blank floppy into drive A:  or  fd0
  • format this disk with fdformat /dev/fd0u1680
  • transfer the image with dd if=dachstein-v1.0.2-1680-optustest.bin of=/dev/fd0
  • to check if the transfer worked then mount /dev/fd0u1680 /mnt/floppy and this list of files should appear under /mnt/floppy

  • total 1486
    drwxr-xr-x    2 root     root         5632 Jan  1  1970 .
    drwxr-xr-x   13 root     root         1024 Feb 17 10:01 ..
    -rwxr-xr-x    1 root     root        44357 Sep 27 14:18 dhclient.lrp
    -rwxr-xr-x    1 root     root        43858 Dec  4 11:55 dhcpd.lrp
    -rwxr-xr-x    1 root     root        23870 Dec  4 11:55 dnscache.lrp
    -rwxr-xr-x    1 root     root        46801 Mar  1 11:00 etc.lrp
    -r-xr-xr-x    1 root     root         6920 May 28  2001 ldlinux.sys
    -rwxr-xr-x    1 root     root       404476 Mar  1 06:43 linux
    -rwxr-xr-x    1 root     root          524 Dec  4 11:56 local.lrp
    -rwxr-xr-x    1 root     root       135236 Mar  1 10:58 modules.lrp
    -rwxr-xr-x    1 root     root         8634 Dec  4 11:56 ramlog.lrp
    -rwxr-xr-x    1 root     root        12376 Dec  4 12:23 readme.txt
    -rwxr-xr-x    1 root     root       715434 Mar  1 08:17 root.lrp
    -rwxr-xr-x    1 root     root          285 Mar  1 08:49 syslinux.cfg
    -rwxr-xr-x    1 root     root          954 Aug 22  2001 syslinux.dpy
    -rwxr-xr-x    1 root     root        67808 Nov  1 21:05 weblet.lrp
    

  • if the above doesn't work out then visit section 1.1.4 of the Ethernet to Ethernet HowTo
  • If you can only use windows to create the floppy then try the shareware WinImage

Date: Thu, 4 Apr 2002 15:41:02 +1000 (EST)
From: Optusnet Support <support.optusnet.com.au>
To: hsd-public.staff.optusnet.com.au
Subject: DHCP-related configuration changes.
NNTP-Posting-Host: 203.2.75.102
X-Trace: 1017898864  4306 203.2.75.102
Xref: news.optusnet.com.au athome.aus.announce:155

Starting Friday 5th April, the Optusnet Cable network will start enforcing
methods of IP allocation. Hence, any clients who are still using a
statically assigned IP address will lose network connectivity. If you have
any problems regarding allocation of an IP via DHCP, please contact our
Customer Support department.