LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 04-10-2017, 08:30 PM   #1
HikoHaieto
LQ Newbie
 
Registered: Mar 2013
Posts: 3

Rep: Reputation: Disabled
Forwarded packets destined for wireless network pass NAT/iptables but aren't received


I have a strange problem I haven't been able to figure out for some time now. I am using a Realtek RTL8188CUS 802.11n WLAN adapter in master mode (using their official driver version 4.0.2_9000.20130911) to act as the wireless access point for my home (using WPA2), and it works at first but I have noticed issues with it or my setup eventually (seemingly at random) dropping and apparently not sending any more packets originating from outside my home network. As far as I'm aware, when the problem occurs it does not work again until a full reboot, though this does not happen often as it's a machine I keep running more or less nonstop (current uptime is at 368 days).

Curiously, clients can still associate with the access point and connectivity with the house's internal network remains intact - I can ping, ssh, access my web server, etc - but fails when attempting to access anything outside the local network. I attempted to add a couple iptables rules to the raw PREROUTING table to trace packets coming from or destined to the wireless network for a designated ping target, and it shows the packets both being received from the wireless device as well as the resulting acknowledgements being translated back to the proper local address and being assigned the correct routing interface before being accepted by my iptables rules. However, the wireless device still never receives said acknowledgements! I also don't see anything suspicious in logs around the time that the wireless network stops being able to access the external one. I'm not quite sure what else to look at to try to figure out what might be going wrong. Any ideas?
 
Old 04-11-2017, 02:35 AM   #2
camp0
Member
 
Registered: Dec 2016
Location: Dublin
Distribution: Fedora
Posts: 70

Rep: Reputation: 4
I would suggest to download the source code of the Realtek RTL driver and compile with debug mode and install that version. Other option is to enable debug messages if the driver supports that option. Check also the routing tables of the machine, is very strange that "fails when attempting to access anything outside the local network".
 
Old 04-11-2017, 01:10 PM   #3
HikoHaieto
LQ Newbie
 
Registered: Mar 2013
Posts: 3

Original Poster
Rep: Reputation: Disabled
It turns out I lied about which driver version I'm using, as I had forgot that realtek's driver died from stagnation and no longer built on newer kernels (I also can't find the outdated driver on their site anymore). The driver I've been using since april 2016 is the same one from realtek, updated unofficially to fix a few bugs and compile on newer kernels, found here: https://github.com/pvaret/rtl8192cu-fixes

I am not aware of a specific debug mode to compile, nor can I find documentation providing directions for compiling the driver with more verbose logging. There is also nothing that looks promising in modinfo:
Code:
filename:       /home/hiko/Desktop/rtl8192cu-fixes/8192cu.ko
version:        v4.0.2_9000.20130911
author:         Realtek Semiconductor Corp.
description:    Realtek Wireless Lan Driver
license:        GPL
srcversion:     340C0C60435AA0500D61BF0
...
depends:        usbcore
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions 
parm:           rtw_ips_mode:The default IPS mode (int)
parm:           ifname:The default name to allocate for first interface (charp)
parm:           if2name:The default name to allocate for second interface (charp)
parm:           rtw_initmac:charp
parm:           rtw_channel_plan:int
parm:           rtw_chip_version:int
parm:           rtw_rfintfs:int
parm:           rtw_lbkmode:int
parm:           rtw_network_mode:int
parm:           rtw_channel:int
parm:           rtw_mp_mode:int
parm:           rtw_wmm_enable:int
parm:           rtw_vrtl_carrier_sense:int
parm:           rtw_vcs_type:int
parm:           rtw_busy_thresh:int
parm:           rtw_ht_enable:int
parm:           rtw_cbw40_enable:int
parm:           rtw_ampdu_enable:int
parm:           rtw_rx_stbc:int
parm:           rtw_ampdu_amsdu:int
parm:           rtw_lowrate_two_xmit:int
parm:           rtw_rf_config:int
parm:           rtw_power_mgnt:int
parm:           rtw_low_power:int
parm:           rtw_wifi_spec:int
parm:           rtw_special_rf_path:int
parm:           rtw_antdiv_cfg:int
parm:           rtw_enusbss:int
parm:           rtw_hwpdn_mode:int
parm:           rtw_hwpwrp_detect:int
parm:           rtw_hw_wps_pbc:int
parm:           rtw_max_roaming_times:The max roaming times to try (uint)
parm:           rtw_force_iol:Force to enable IOL (bool)
parm:           rtw_mc2u_disable:int
parm:           rtw_mac_phy_mode:int
parm:           rtw_80211d:int
parm:           rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint)
Perhaps I should mention I'm running debian jessie 8.4 with the following kernel: Linux votocon 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) x86_64 GNU/Linux

So you can see the ping packets I mentioned going through my tables, here is a simple trace coming from the wireless device, where the default policies are set to ACCEPT:
Code:
Apr 11 13:29:55 votocon kernel: [31925184.693562] TRACE: raw:PREROUTING:policy:3 IN=wlan0 OUT= MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693574] TRACE: mangle:PREROUTING:policy:1 IN=wlan0 OUT= MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693579] TRACE: nat:PREROUTING:policy:2 IN=wlan0 OUT= MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693587] TRACE: mangle:FORWARD:policy:1 IN=wlan0 OUT=eth0 MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693591] TRACE: filter:FORWARD:rule:2 IN=wlan0 OUT=eth0 MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693597] TRACE: filter:ban-out:return:4 IN=wlan0 OUT=eth0 MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693600] TRACE: filter:FORWARD:policy:5 IN=wlan0 OUT=eth0 MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693604] TRACE: security:FORWARD:policy:1 IN=wlan0 OUT=eth0 MAC=00:0b:81:84:37:27:7c:d1:c3:e7:e1:d3:08:00 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693607] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=eth0 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.693610] TRACE: nat:POSTROUTING:rule:1 IN= OUT=eth0 SRC=192.168.8.103 DST=217.23.9.18 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=2018 PROTO=ICMP TYPE=8 CODE=0 ID=48650 SEQ=0
Similarly, here is the response being routed back to the wireless device, showing that the packet was successfully delivered to the ping destination, a response received, that response mapped to the correct local address (192.168.8.103), and finally making its way through the rest of the tables:
Code:
Apr 11 13:29:55 votocon kernel: [31925184.820419] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=50.142.252.91 LEN=84 TOS=0x00 PREC=0x20 TTL=49 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820449] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=50.142.252.91 LEN=84 TOS=0x00 PREC=0x20 TTL=49 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820461] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=wlan0 MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=192.168.8.103 LEN=84 TOS=0x00 PREC=0x20 TTL=48 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820465] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=wlan0 MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=192.168.8.103 LEN=84 TOS=0x00 PREC=0x20 TTL=48 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820472] TRACE: filter:ban-in:return:4 IN=eth0 OUT=wlan0 MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=192.168.8.103 LEN=84 TOS=0x00 PREC=0x20 TTL=48 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820476] TRACE: filter:FORWARD:policy:5 IN=eth0 OUT=wlan0 MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=192.168.8.103 LEN=84 TOS=0x00 PREC=0x20 TTL=48 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820480] TRACE: security:FORWARD:policy:1 IN=eth0 OUT=wlan0 MAC=30:85:a9:9a:3f:dc:5c:83:8f:5e:ac:22:08:00 SRC=217.23.9.18 DST=192.168.8.103 LEN=84 TOS=0x00 PREC=0x20 TTL=48 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0 
Apr 11 13:29:55 votocon kernel: [31925184.820483] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=wlan0 SRC=217.23.9.18 DST=192.168.8.103 LEN=84 TOS=0x00 PREC=0x20 TTL=48 ID=7705 PROTO=ICMP TYPE=0 CODE=0 ID=48650 SEQ=0
 
  


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
can sniffed packets be forwarded to a different network? jkmin96 Linux - Networking 11 02-15-2011 10:07 PM
Using promiscuous interface and iptables to receive packets not destined to localhost anaidu Linux - Networking 2 03-23-2010 05:07 PM
iptables:redirect ports except for packets destined for fierwall(upto 256 ip) itself mmshekiba Linux - Security 1 02-02-2006 12:08 PM
Kernel 2.6.11.12 fixes Network Bridge Incorrectly Forwarded Packets unSpawn Linux - Security 0 11-23-2005 07:25 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 09:21 PM.

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