You are not logged in.
The Leopard machines on our LAN have working internet on boot, my Arch box does not?
Even though I have the IPCop server's IP in the Arch /etc/resolv.conf.head file, I still have to do a sudo /etc/rc.d/network restart before I can use the internet.
Does anyone know how I can solve this one?
Thanks for your time.
Last edited by handy (2008-12-13 13:41:04)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
I have always used DHCP, never had a static IP address.
Apart from /etc/resolv.conf.head & /etc/rc.conf is there anywhere else I can look that is involved in the network startup & configuration?
Thanks for your time.
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
Arch network services will only start at boot time if you have configured them to do so. The simplest way to do this is by editing the network section of /etc/rc.conf. There are also other tools, such as netcfg, networkmanager, etc.
Offline
Thanks for your reply. :-)
I'm sorry, my description has been too sparse, so I'll be more specific:
I have had no problems accessing the internet for most of this year that I have been using Arch. I have just set up an IPCop firewall & web proxy server, which is now behind a modem/router (that is in bridge mode, so it is now acting as a transparent modem) & in front of a 24 port switch.
The Mac Leopard machines & a Sabayon machine are all operating as they were before the IPCop server went online; they can all access the internet from their desktop environments after a reboot.
The Arch/Xfce machine can not access the internet after a reboot, it must have a sudo /etc/rc.d/network restart & then it works beautifully?
So, my question is all about how can I get Arch to be able to use the internet without having to give it the network restart command every time it boots up?
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
Well.. assuming your network is correctly configured to start on boot (you still haven't said exactly), you should check the logs on both the Arch box and IPCop, to see what's happening to the boot-time dhcp negotiation. Compare those logs with the entired generated later when the negotiation is successful.
Offline
Well.. assuming your network is correctly configured to start on boot (you still haven't said exactly),
This is a simple home network, that, at this stage, does not share information between machines, it only exists to access the internet & a printer that is on the LAN.
There have been no problems with any of the machines booting & being able to access the internet either before or after I started using the IPCop firewall/web proxy.
Except of course for the Arch box, which was setup according to the Beginners Guide last April. The rc.conf is correct in all sections, & I believe that the resolv.conf.head & /etc/hosts is also correct, dhcpcd.conf is as installed. Beyond that I don't know what else needs to be configured by me for the basic DHCP functioning of the machine?
I looked in /var/log/ & could find nothing relating to the network that indicated a problem. Though I was in unfamiliar territory.
I'll reboot the machine now & see what I get in the logs & report back.
[Edit:] No, I can find nothing to indicate why the Arch box has changed its behaviour?
Last edited by handy (2008-12-08 10:07:11)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
Here's a typical dhcp transaction between my IPCop and one of my Arch boxes:
13:25:35 tk-gwa dhcpcd[2878]: eth0: renewing lease of 192.168.10.69
13:25:35 tk-gwa dhcpcd[2878]: eth0: acknowledged 192.168.10.69 from 192.168.10.1
13:25:35 tk-gwa dhcpcd[2878]: eth0: leased 192.168.10.69 for 172800 seconds
13:25:38 dhcpd DHCPREQUEST for 192.168.10.69 from 00:04:e2:20:07:2f via eth0
13:25:38 dhcpd DHCPACK on 192.168.10.69 to 00:04:e2:20:07:2f via eth0
i.e. the Arch client requests the address, the IPCop server processes the request. If you're seeing anything different on either side, post it here.
As the failure is only at boot-time, do a reboot before checking the logs. It may be that there is a delay initialising the driver for your network card, so your dmesg directly after reboot would also be useful.
Offline
Thanks very much for your reply, I will investigate it further tomorrow after sleep. :-)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
did you change to the new dhcpd.pacnew file in /etc/conf.d?
Offline
did you change to the new dhcpd.pacnew file in /etc/conf.d?
This is the contents of my dhcpd file:
#
# Arguments to be passed to the DHCP client daemon
#
DHCPCD_ARGS="-q"
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
I can find nothing in the Arch /var/logs/ that were updated when I rebooted that shows dhcpd doing anything.
The following is in dmesg shows the following:
sky2 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
sky2 0000:05:00.0: setting latency timer to 64
sky2 0000:05:00.0: v1.22 addr 0x50200000 irq 17 Yukon-2 EC Ultra rev 3
sky2 eth0: addr 00:1b:63:b1:36:46
IPCop's dhcp server log shows the following which would have happened after I input network restart:
14:00:09 dhcpd DHCPDISCOVER from 00:1b:63:b1:36:46 (archtypical) via eth0
14:00:10 dhcpd DHCPOFFER on 192.168.1.22 to 00:1b:63:b1:36:46 (archtypical) via eth0
14:00:14 dhcpd DHCPREQUEST for 192.168.1.22 (192.168.1.1) from 00:1b:63:b1:36:46 (archtypical) via eth0
14:00:14 dhcpd DHCPACK on 192.168.1.22 to 00:1b:63:b1:36:46 (archtypical) via eth0
Last edited by handy (2008-12-09 04:58:16)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
Looks like I just have to live with it eh!?
Oh, well, it isn't to hard to live with, I just though someone might know how to fix it.
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
Post your /etc/rc.conf. If '/etc/rc.d/network start' works but network-at-boot-time doesn't, that's where the error is.
Incidentally, dhcpcd messages don't show up in dmesg - you should be looking in messages.log or everything.log.
Offline
you don't have network backgrounded, do you? you need to post your rc.conf including the daemons array.
Offline
Post your /etc/rc.conf. If '/etc/rc.d/network start' works but network-at-boot-time doesn't, that's where the error is.
As a workaround I've put /etc/rc.d/network start in my /etc/rc.local & now I don't have to type it manually.
Incidentally, dhcpcd messages don't show up in dmesg - you should be looking in messages.log or everything.log.
I looked in all the logs that had been changed after a boot.
Here is my rc.conf:
#
# /etc/rc.conf - Main Configuration for Arch Linux
#
#
# -----------------------------------------------------------------------
# LOCALIZATION
# -----------------------------------------------------------------------
#
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
LOCALE="en_AU.utf8"
HARDWARECLOCK="UTC"
TIMEZONE="Australia/Sydney"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
#
# -----------------------------------------------------------------------
# HARDWARE
# -----------------------------------------------------------------------
#
# Scan hardware and load required modules at bootup
MOD_AUTOLOAD="yes"
# Module Blacklist - modules in this list will never be loaded by udev
MOD_BLACKLIST=(net-pf-10 pcspkr) ## turns off ipv6 & pc speaker
#
# Modules to load at boot-up (in this order)
# - prefix a module with a ! to blacklist it
#
MODULES=(sky2 snd-mixer-oss snd-pcm-oss snd-hwdep snd-page-alloc snd-pcm snd-timer snd snd-hda-intel soundcore fglrx)
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"
#
# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
HOSTNAME="archtypical"
#
# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available
# interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
#
# Note: to use DHCP, set your interface to be "dhcp" (eth0="dhcp")
#
###lo="lo 127.0.0.1"
# eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
eth0="dhcp"
###INTERFACES=(lo eth0)
INTERFACES=(eth0)
#
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
#
# gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
#
# Enable these network profiles at boot-up. These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
# - set to 'menu' to present a menu during boot-up (dialog package required)
# - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network-profiles
#
#NET_PROFILES=(main)
#
# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(syslog-ng @iptables @network @netfs @crond @alsa @portmap @sshd @transmission-daemon @stb-admin @fam @gpm)# @tor @privoxy # @hal - hal's out on account of worker
# End of file
Last edited by handy (2008-12-13 12:30:42)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
you don't have network backgrounded, do you? you need to post your rc.conf including the daemons array.
Yes I do have network backgrounded? That is no good? Does that prevent associated events being written to logs?
rc.conf is above.
Last edited by handy (2008-12-11 06:49:30)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
So is my rc.conf posted above in post_ 15 ok?
I would really like for there to be an error in there that was causing this strange situation.
Last edited by handy (2008-12-13 08:00:05)
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline
Try un-backgrounding iptables. At the moment you are effectively starting them in parallel - maybe iptables needs to be fully up and running before you start your network.
Offline
Try un-backgrounding iptables. At the moment you are effectively starting them in parallel - maybe iptables needs to be fully up and running before you start your network.
Yep, you were right.
Removing the @ from iptables in the rc.conf DAEMONS= line fixed the problem.
Quite obvious in hindsight. lol
Thank you very much for your help tomk, it is truly very much appreciated.
I used to be surprised that I was still surprised by my own stupidity, finding it strangely refreshing.
Well, now I don't find it refreshing.
I'm over it!
Offline