[SOLVED] Strange networking problem with slack 13.1/pfsense router
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
# /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"
"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.
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?
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
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?
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
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.
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...
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.
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!?...
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Strange networking problem with slack 13.1/pfsense router
). I went through something similar to your current experience with the r8169 module and r81** nics a while back. 
