LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-25-2011, 10:58 AM   #1
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Rep: Reputation: Disabled
Question Strange networking problem with slack 13.1/pfsense router


Hi guys!

I opened a thread on the general networking section of the forums to discuss about a problem I am experiencing with a newly installed slackware 13.1 (not 64b) on my dell laptop.

Basically, the machine is not getting an IP from the dhcp server on my pfsense router.

All other machines on my network are still getting IP's fine, and the pfsense box never changed.

I can get an IP from the pfsense box by manually loging as root and using /etc/rc.d/rc.inet1 eth0 restart (note the argument eth0 necessary to get the ip).

User markush at the link below suggested I open this thread here, I think its a great idea since I believe it is a slackware problem. he also recommended to use tcpdump to diagnose the connection problem. Here's the results:

I issued the dhcp renewal commands in a terminal and monitored the output of tcpdump in a different terminal.

Code:
root@xpsm1730:/home/lpallard# /etc/rc.d/rc.inet1 restart
Polling for DHCP server on interface eth0:
dhcpcd: version 5.2.2 starting
dhcpcd: eth0: waiting for carrier
dhcpcd: timed out
dhcpcd: allowing 8 seconds for IPv4LL timeout
dhcpcd: timed out
resulted in

Code:
root@xpsm1730:/home/lpallard# tcpdump -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:36:47.535170 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:36:47.884176 IP6 :: > ff02::1:ff48:97c8: ICMP6, neighbor solicitation, who has fe80::21d:9ff:fe48:97c8, length 24
20:36:48.887181 IP6 fe80::21d:9ff:fe48:97c8 > ff02::2: ICMP6, router solicitation, length 16
20:36:52.755174 IP6 fe80::21d:9ff:fe48:97c8 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
20:36:52.899178 IP6 fe80::21d:9ff:fe48:97c8 > ff02::2: ICMP6, router solicitation, length 16
20:36:56.907173 IP6 fe80::21d:9ff:fe48:97c8 > ff02::2: ICMP6, router solicitation, length 16
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
and

Code:
root@xpsm1730:/home/lpallard# /etc/rc.d/rc.inet1 eth0 restart
Polling for DHCP server on interface eth0:
dhcpcd: version 5.2.2 starting
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: offered 192.168.0.106 from 192.168.0.100
dhcpcd: eth0: acknowledged 192.168.0.106 from 192.168.0.100
dhcpcd: eth0: checking for 192.168.0.106
dhcpcd: eth0: leased 192.168.0.106 for 28800 seconds
dhcpcd: forking to background
resulted in

Code:
root@xpsm1730:/home/lpallard# tcpdump -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:37:48.360226 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1d:09:48:97:c8 (oui Unknown), length 324
20:37:48.360808 IP 192.168.0.100.bootps > 192.168.0.106.bootpc: BOOTP/DHCP, Reply, length 300
20:37:48.360925 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1d:09:48:97:c8 (oui Unknown), length 336
20:37:48.361240 IP 192.168.0.100.bootps > 192.168.0.106.bootpc: BOOTP/DHCP, Reply, length 300
20:37:48.373233 ARP, Request who-has 192.168.0.106 tell 0.0.0.0, length 28
20:37:49.965947 ARP, Request who-has 192.168.0.106 tell 0.0.0.0, length 28
20:37:51.499654 ARP, Request who-has 192.168.0.106 tell 0.0.0.0, length 28
20:37:53.539188 ARP, Request who-has 192.168.0.106 tell 192.168.0.106, length 28
20:37:55.541183 ARP, Request who-has 192.168.0.106 tell 192.168.0.106, length 28
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
which worked (got 192.168.0.106 from pfsense)

I believe the router is fine since all other machines are all using slackware 13.1 (one slackware 32bit and the other slackeware 64) and are all handshaking perfectly with the pfsense box.

I also believe the kernel on the faulty machine is OK since I am using the very same kernel(2.6.37) on the machine running slack64 and this machine is also handshaking perfectly with my pfsense box.

Please see http://www.linuxquestions.org/questi...get-ip-857683/ for more details.

Last edited by lpallard; 01-25-2011 at 11:00 AM.
 
Old 01-25-2011, 02:29 PM   #2
+Alan Hicks+
Member
 
Registered: Feb 2005
Distribution: Slackware
Posts: 72

Rep: Reputation: 55
This is a good question! Could you please provide the following files?

/etc/rc.d/rc.inet1.conf
/etc/udev/rules.d/70-persistent-net.rules

Also, run this command and post its output:

ifconfig -a

Once that's done, I think the problem will become apparent.
 
Old 01-25-2011, 06:31 PM   #3
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
Here you go!!

/etc/rc.d/rc.inet1.conf
Code:
# /etc/rc.d/rc.inet1.conf
#
# This file contains the configuration settings for network interfaces.
# If USE_DHCP[interface] is set to "yes", this overrides any other settings.
# If you don't have an interface, leave the settings null ("").

# You can configure network interfaces other than eth0,eth1... by setting
# IFNAME[interface] to the interface's name. If IFNAME[interface] is unset
# or empty, it is assumed you're configuring eth<interface>.

# Several other parameters are available, the end of this file contains a
# comprehensive set of examples.

# =============================================================================

# Config information for eth0:
IPADDR[0]=""
NETMASK[0]=""
USE_DHCP[0]="yes"
DHCP_HOSTNAME[0]=""

# Config information for eth1:
#IPADDR[1]=""
#NETMASK[1]=""
#USE_DHCP[1]=""
#DHCP_HOSTNAME[1]=""

# Config information for eth2:
#IPADDR[2]=""
#NETMASK[2]=""
#USE_DHCP[2]=""
#DHCP_HOSTNAME[2]=""

# Config information for eth3:
#IPADDR[3]=""
#NETMASK[3]=""
#USE_DHCP[3]=""
#DHCP_HOSTNAME[3]=""

# Default gateway IP address:
GATEWAY=""

# Change this to "yes" for debugging output to stdout.  Unfortunately,
# /sbin/hotplug seems to disable stdout so you'll only see debugging output
# when rc.inet1 is called directly.
DEBUG_ETH_UP="no"

## Example config information for wlan0.  Uncomment the lines you need and fill
## in your info.  (You may not need all of these for your wireless network)
#IFNAME[4]="wlan0"
#IPADDR[4]=""
#NETMASK[4]=""
#USE_DHCP[4]="yes"
#DHCP_HOSTNAME[4]="icculus-wireless"
#DHCP_KEEPRESOLV[4]="yes"
#DHCP_KEEPNTP[4]="yes"
#DHCP_KEEPGW[4]="yes"
#DHCP_IPADDR[4]=""
#WLAN_ESSID[4]=BARRIER05
#WLAN_MODE[4]=Managed
##WLAN_RATE[4]="54M auto"
##WLAN_CHANNEL[4]="auto"
##WLAN_KEY[4]="D5AD1F04ACF048EC2D0B1C80C7"
##WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=96389dc66eaf7e6efd5b5523ae43c7925ff4df2f8b7099495192d44a774fda16"
#WLAN_WPA[4]="wpa_supplicant"
#WLAN_WPADRIVER[4]="ndiswrapper"

## Some examples of additional network parameters that you can use.
## Config information for wlan0:
#IFNAME[4]="wlan0"              # Use a different interface name nstead of
                                # the default 'eth4'
#HWADDR[4]="00:01:23:45:67:89"  # Overrule the card's hardware MAC address
#MTU[4]=""                      # The default MTU is 1500, but you might need
                                # 1360 when you use NAT'ed IPSec traffic.
#DHCP_KEEPRESOLV[4]="yes"       # If you dont want /etc/resolv.conf overwritten
#DHCP_KEEPNTP[4]="yes"          # If you don't want ntp.conf overwritten
#DHCP_KEEPGW[4]="yes"           # If you don't want the DHCP server to change
                                # your default gateway
#DHCP_IPADDR[4]=""              # Request a specific IP address from the DHCP
                                # server
#WLAN_ESSID[4]=DARKSTAR         # Here, you can override _any_ parameter
                                # defined in rc.wireless.conf, by prepending
                                # 'WLAN_' to the parameter's name. Useful for
                                # those with multiple wireless interfaces.
#WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=TKIP | set WPAPSK=thekey"
                                # Some drivers require a private ioctl to be
                                # set through the iwpriv command. If more than
                                # one is required, you can place them in the
                                # IWPRIV parameter (separated with the pipe (|)
                                # character, see the example).
/etc/udev/rules.d/70-persistent-net.rules
Code:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:0x1672 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:09:48:97:c8", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x4229 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1f:3b:7b:ba:e5", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
ifconfig -a (after I got an IP from pfsense)
Code:
eth0      Link encap:Ethernet  HWaddr 00:1d:09:48:97:c8  
          inet addr:192.168.0.106  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:9ff:fe48:97c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:137 errors:0 dropped:0 overruns:0 frame:0
          TX packets:105 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:15350 (14.9 KiB)  TX bytes:17985 (17.5 KiB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

vboxnet0  Link encap:Ethernet  HWaddr 0a:00:27:00:00:00  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:1f:3b:7b:ba:e5  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
I hope this will help!
Everything else I can provide, please let me know.

Last edited by lpallard; 01-25-2011 at 06:33 PM.
 
Old 01-26-2011, 07:38 PM   #4
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Leinster, IE
Distribution: Slackware, NetBSD
Posts: 2,225

Rep: Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793Reputation: 1793
"Waiting for a carrier" appears in one of your tcpdump outputs. Have you tried another patch cable? Have you tried that patch cable on another DHCP client to confirm it's OK?

Have you tried connecting to pfSense directly with a crossover cable, bypassing your hub/switch? Have you tried disconnecting from pfSense and connecting directly to another DHCP server, on your ISP router for example? Perhaps there is an intermittent hardware issue, like a badly-crimped patch cable perhaps. Try turning off PXE booting in your laptop BIOS as well; perhaps there is an issue there. Update the BIOS if so.
 
Old 01-26-2011, 08:30 PM   #5
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
Quote:
Have you tried another patch cable?
Yes, same behavior...

Quote:
Have you tried that patch cable on another DHCP client to confirm it's OK?
Yes, the other machines are getting an IP fine using the cable

Quote:
Have you tried connecting to pfSense directly with a crossover cable, bypassing your hub/switch?
Yes, same behavior

Quote:
Have you tried disconnecting from pfSense and connecting directly to another DHCP server, on your ISP router for example?
Not yet... see my comments below

Quote:
Perhaps there is an intermittent hardware issue, like a badly-crimped patch cable perhaps.
Very unlikely. I can get an IP woth the PXE boot and with live distros like parted magic, ubuntu live, gentoo live, etc...

Quote:
Try turning off PXE booting in your laptop BIOS as well; perhaps there is an issue there. Update the BIOS if so.
I dont believe the hardware of the laptop is faulty due to the fact that it happens only in slackware and happens the same way all the time (fails the first time but works by manually getting an IP)

I seriously believe slackware is the root cause... somehow, this problem started immediately after I reinstalled slack from scratch. It never happened before. Also, I tried to isolate the components by elimination starting with:

the laptop hardware: it is not faulty since i get IP's with every other environments (OS's or live distros)
the kernel: It is not faulty since I have the same kernel on my htpc and it gets an ip just fine
the pfsense router: it is not faulty since all other machines are still getting ip's fine, even guest machines such as my girlfriend's iphone/laptop and my friend's laptops are getting IP's fine
the cabling/switches: they are not faulty as I swapped everything around and it did not solve the problem

My best bet would be a corrupted library or module or a core slack file (bad CRC). I did check the CD's md5 to be sure and they were fine... but who knows.. Any other ideas?

Feedback appreciated !

Last edited by lpallard; 01-26-2011 at 08:32 PM.
 
Old 01-26-2011, 08:52 PM   #6
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,860

Rep: Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229Reputation: 2229
The kernel for Slackware 13.1 most certainly is not 2.6.37.

It's 2.6.33.4.
 
Old 01-26-2011, 08:55 PM   #7
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 224Reputation: 224Reputation: 224
Quote:
Originally Posted by lpallard View Post
I just realized that since I reinstalled slackware on my laptop, the machine is not obtaining an IP from my router during the startup proccess like it used to do before.
Quote:
Originally Posted by lpallard View Post
the kernel: It is not faulty since I have the same kernel on my htpc and it gets an ip just fine

My best bet would be a corrupted library or module or a core slack file (bad CRC). I did check the CD's md5 to be sure and they were fine... but who knows.. Any other ideas?

Feedback appreciated !
What happens with the Slackware provided huge or generic kernels?

Is your HTPC using the exact same NIC (model, revision, capabilities, bios option ...). The tg3 module had some poking in recent kernels.

There's no reason /etc/rc.d/rc.inet1 restart would be any different than /etc.rc.d/rc.inet1 eth0 restart in the stock environment. Do/did you install wicd, network manager, or something else the manipulates network scripts?
 
Old 01-26-2011, 09:18 PM   #8
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
The kernel for Slackware 13.1 most certainly is not 2.6.37.

Did I mentioned that the stock kernel of slack 13.1 was 2.6.37?? If so I apologize, I did not want to confuse anybody. I upgraded the kernel cause the stock 2.6.33.4 was too old for half of my hardware...

Quote:
What happens with the Slackware provided huge or generic kernels?
Haha very good call. I did not even thought about trying the stock kernel again to see if it happens... Between the moment I installed slack with 2.6.33.4 and the moment I built my own kernel, I might have used the machine 20 minutes or so... Dont remember what happened that night.

I will try tomorrow with booting from the stock kernel and see... I guess it will be the ultimate test.

Quote:
The tg3 module had some poking in recent kernels
Mmmmmm... really? I am using tg3 on the laptop.

Quote:
Is your HTPC using the exact same NIC (model, revision, capabilities, bios option ...)
Not at all...

Laptop:
Code:
9:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754M Gigabit Ethernet PCI Express (rev 02)
        Subsystem: Dell Device 01f7
        Flags: bus master, fast devsel, latency 0, IRQ 43
        Memory at eeff0000 (64-bit, non-prefetchable) [size=64K]
        Expansion ROM at <ignored> [disabled]
        Capabilities: [48] Power Management version 3
        Capabilities: [50] Vital Product Data
        Capabilities: [58] Vendor Specific Information <?>
        Capabilities: [e8] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [d0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [13c] Virtual Channel <?>
        Capabilities: [160] Device Serial Number 00-1d-09-ff-fe-48-97-c8
        Capabilities: [16c] Power Budgeting <?>
        Kernel driver in use: tg3
        Kernel modules: tg3
HTPC:
Code:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
        Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 40
        I/O ports at e800 [size=256]
        Memory at fbfff000 (64-bit, prefetchable) [size=4K]
        Memory at fbff8000 (64-bit, prefetchable) [size=16K]
        Expansion ROM at febf0000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
        Capabilities: [cc] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel <?>
        Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
        Kernel driver in use: r8169
        Kernel modules: r8169
Quote:
There's no reason /etc/rc.d/rc.inet1 restart would be any different than /etc.rc.d/rc.inet1 eth0 restart in the stock environment. Do/did you install wicd, network manager, or something else the manipulates network scripts?
I agree. They should result in the same behavior. No I did not install anything network related. Only stock scripts

Last edited by lpallard; 01-26-2011 at 09:20 PM.
 
Old 01-26-2011, 09:36 PM   #9
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 224Reputation: 224Reputation: 224
Quote:
Originally Posted by lpallard View Post
Haha very good call. I did not even thought about trying the stock kernel again to see if it happens... Between the moment I installed slack with 2.6.33.4 and the moment I built my own kernel, I might have used the machine 20 minutes or so... Dont remember what happened that night.

I will try tomorrow with booting from the stock kernel and see... I guess it will be the ultimate test.


Mmmmmm... really? I am using tg3 on the laptop.
Give it a try (the stock kernels that is ). I went through something similar to your current experience with the r8169 module and r81** nics a while back.

I read through your other thread and notice you were using the tg3 module, look at the change log for .37, and saw this -
Code:
tg3: fix return value check in tg3_read_vpd()
    
    Besides -ETIMEDOUT and -EINTR, pci_read_vpd may return other error
    values like -ENODEV or -EINVAL which are ignored due to the buggy
    check, but the data are not read from VPD anyway and this is checked
    subsequently with at most 3 needless loop iterations. This does not
    show up as a runtime bug.

tg3: Do not call device_set_wakeup_enable() under spin_lock_bh
    
    The tg3 driver calls device_set_wakeup_enable() under spin_lock_bh,
    which causes a problem to happen after the recent core power
    management changes, because this function can sleep now.  Fix this
    by moving the device_set_wakeup_enable() call out of the
    spin_lock_bh-protected area.
Then there's this - http://forums.gentoo.org/viewtopic-t...6-start-0.html (sounds like your exact issue). States it's fixed in .37 - perhaps not?

I'd mess around with adding the modprobe lines to rc.M. Flaky kernel module it looks to be
 
1 members found this post helpful.
Old 01-27-2011, 12:00 PM   #10
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
bang on!

disturbed1 you are one of my linux heroes! I will look at this tonight and post back!
 
Old 01-27-2011, 08:31 PM   #11
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
It does not seems to be fixed in .37

http://bugs.gentoo.org/show_bug.cgi?id=333035 does not specify if its fixed and the person who stated its fixed at the link you provided did not support the statement.

also adding the modprobe lines to rc.M, do I only need to add "modprobe tg3" to rc.M? if so where in the file? Its a critical script I cant afford to cook it...

Last edited by lpallard; 01-27-2011 at 08:35 PM.
 
Old 01-27-2011, 09:26 PM   #12
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 224Reputation: 224Reputation: 224
The bug you linked to is for e1000. Intel's gigabit ethernet card. With links to a fault in dhcpcd in 2.6.35 and post kernels. Your subject states Slackware 13.1, which uses a kernel previous to 2.6.35. Current uses the .35 kernel, but has had an updated dhcpcd. So now you're into another area altogether I assumed since you deviated from upstream stable Slackware you would have done due diligence for system compatibility, and hopefully not following the flawed newer version must be better

Somewhere around line 85 is where rc.inet1 is called. The module needs to be loaded before this.

Code:
echo "Modprobe tg3"
/sbin/modprobe -v tg3
sleep 5

# Initialize the networking hardware.
if [ -x /etc/rc.d/rc.inet1 ]; then
  . /etc/rc.d/rc.inet1
fi
You can try that.
/etc/rc.d/rc.modules would be another place (some would argue more correct ). But this file can get overwritten after kernel updates.

If this doesn't work, then you'll need to compare the deviations you've made from stock 13.1 to your system. I'd start with an upgrade dhcpcd at the minimum.
 
Old 01-28-2011, 06:39 AM   #13
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
My laptop is more or less my "testing" machine... Thats the only machine on my network I allow unstable software to be installed. No I did not check the changes or compatibility at all. I thought worst case, I will reinstall alltogether or revert to the stock generic kernel.

Code:
echo "Modprobe tg3"
/sbin/modprobe -v tg3
sleep 5
Thats what I thought. Just trying not to fry the scripts for no reasons.. haha

I will try the script modification and see. Maybe also updating dhcpcd!?...

WIll post back.
 
Old 01-28-2011, 12:42 PM   #14
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 224Reputation: 224Reputation: 224
Quote:
Originally Posted by lpallard View Post
I will try the script modification and see. Maybe also updating dhcpcd!?...

WIll post back.
Also -- don't forget to try the stock kernel. Doing that will yield a bit of troubleshooting help.
 
Old 01-28-2011, 09:32 PM   #15
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,047

Original Poster
Rep: Reputation: Disabled
OK I can confirm the kernel or modules are to be blamed. I tried without modifying the rc.M script and with the stock 2.6.33.4 generic kernel and I can get an IP at boot time.

Output of /var/log/messages using the stock kernel:

Code:
Jan 28 22:17:46 xpsm1730 dhcpcd: eth0: renewing lease of 192.168.0.106
Jan 28 22:17:47 xpsm1730 dhcpcd: eth0: acknowledged 192.168.0.106 from 192.168.0.100
Jan 28 22:17:47 xpsm1730 dhcpcd: eth0: leased 192.168.0.106 for 28800 seconds
Jan 28 22:19:03 xpsm1730 logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -k -d eth0
Jan 28 22:19:03 xpsm1730 dhcpcd: eth0: releasing lease of 192.168.0.106
Jan 28 22:19:03 xpsm1730 dhcpcd: eth0: removing interface
Jan 28 22:19:58 xpsm1730 kernel: tg3 0000:09:00.0: eth0: Tigon3 [partno(BCM95754m) rev b002] (PCI Express) MAC address 00:1d:09:48:97:c8
Jan 28 22:19:58 xpsm1730 kernel: tg3 0000:09:00.0: eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1])
Jan 28 22:19:58 xpsm1730 kernel: tg3 0000:09:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
Jan 28 22:19:58 xpsm1730 kernel: tg3 0000:09:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
Jan 28 22:19:58 xpsm1730 logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -t 10  eth0
Jan 28 22:20:00 xpsm1730 dhcpcd: eth0: waiting for carrier
Jan 28 22:20:04 xpsm1730 kernel: tg3 0000:09:00.0: eth0: Link is up at 1000 Mbps, full duplex
Jan 28 22:20:04 xpsm1730 kernel: tg3 0000:09:00.0: eth0: Flow control is on for TX and on for RX
Jan 28 22:23:43 xpsm1730 logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -k -d eth0
Jan 28 22:24:30 xpsm1730 kernel: eth0: Tigon3 [partno(BCM95754m) rev b002] (PCI Express) MAC address 00:1d:09:48:97:c8
Jan 28 22:24:30 xpsm1730 kernel: eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1])
Jan 28 22:24:30 xpsm1730 kernel: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
Jan 28 22:24:30 xpsm1730 kernel: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
Jan 28 22:24:32 xpsm1730 logger: /etc/rc.d/rc.inet1:  /sbin/dhcpcd -t 10  eth0
Jan 28 22:24:33 xpsm1730 dhcpcd: eth0: waiting for carrier
Jan 28 22:24:36 xpsm1730 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jan 28 22:24:36 xpsm1730 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jan 28 22:24:36 xpsm1730 dhcpcd: eth0: carrier acquired
Jan 28 22:24:36 xpsm1730 dhcpcd: eth0: broadcasting for a lease
Jan 28 22:24:39 xpsm1730 dhcpcd: eth0: offered 192.168.0.106 from 192.168.0.100
Jan 28 22:24:39 xpsm1730 dhcpcd: eth0: acknowledged 192.168.0.106 from 192.168.0.100
Jan 28 22:24:39 xpsm1730 dhcpcd: eth0: checking for 192.168.0.106
Jan 28 22:24:44 xpsm1730 dhcpcd: eth0: leased 192.168.0.106 for 28800 seconds
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] PXE boot with pfSense and Slack lpallard Slackware 8 09-28-2010 11:13 AM
Suggestions on this Linux Networking structure - Using PFSense,Apache,Postgresql bstar Linux - Networking 0 08-16-2010 06:55 PM
LXer: Protect your network with pfSense firewall/router LXer Syndicated Linux News 0 10-03-2008 05:40 PM
Strange networking problem in 9.2 El Basto SUSE / openSUSE 5 06-10-2005 04:40 AM
Strange networking problem webdwarf Debian 2 08-02-2004 01:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 01:27 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration