LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
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 06-05-2011, 01:20 PM   #1
doru
Member
 
Registered: Sep 2008
Distribution: Ubuntu 8.04 LTS Server
Posts: 89

Rep: Reputation: 16
how does the dhcp offer get through this iptables configuration?


eth0 is configured through a dhcp server connected directly to it.
http://en.wikipedia.org/wiki/Dhcp#DHCP_offer is very clear: the answer of the server is a UDP to 255.255.255.255. Please tell me how can it pass through this iptables configuration, because it does.
Code:
iptables -nvL INPUT
(policy DROP)
 3281  201K ACCEPT     all  --  eth1   *       192.168.69.0/24      0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       127.0.0.1            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       192.168.69.1         0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       93.114.xx.xx         0.0.0.0/0
 1253 93310 ACCEPT     all  --  *      *       0.0.0.0/0            93.114.xx.xx        state RELATED,ESTABLISHED
  108  5388 tcp_packets  tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0         
 2724  258K udp_packets  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0         
    1    56 icmp_packets  icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0        
   56  1568 DROP       all  --  eth0   *       0.0.0.0/0            224.0.0.0/8

iptables -nvL udp_packets
    0     0 DROP       udp  --  eth0   *       0.0.0.0/0            93.114.xx.xx        udp dpts:135:139
   18  5923 DROP       udp  --  eth0   *       0.0.0.0/0            255.255.255.255     udp dpts:67:68
Maybe iptables is started after eth0 is configured, in spite of my pre-up iptables-restore [...] in eth0 configuration?

Last edited by doru; 06-05-2011 at 01:29 PM. Reason: afterthought
 
Old 06-05-2011, 01:26 PM   #2
smoker
Senior Member
 
Registered: Oct 2004
Distribution: Fedora Core 4, 12, 13, 14, 15, 17
Posts: 2,279

Rep: Reputation: 248Reputation: 248Reputation: 248
Because the firewall is designed to block / direct unsolicited packets from outside. You said yourself that the DHCP server is sending an answer, so your system must have requested that answer, and so the firewall does not block it.
 
Old 06-05-2011, 01:31 PM   #3
doru
Member
 
Registered: Sep 2008
Distribution: Ubuntu 8.04 LTS Server
Posts: 89

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by smoker View Post
Because the firewall is designed to block / direct unsolicited packets from outside. You said yourself that the DHCP server is sending an answer, so your system must have requested that answer, and so the firewall does not block it.
If you refer to this line:
Code:
 1253 93310 ACCEPT     all  --  *      *       0.0.0.0/0            93.114.xx.xx        state RELATED,ESTABLISHED
then you should explain why is a package accepted even though it has a destination of 255.255.255.255, when the required destination is 93.114.xx.xx.
 
Old 06-05-2011, 01:32 PM   #4
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,415

Rep: Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968
Have you actually looked at the response? Just checking mine, it's actually addressed to the address in the offer itself.

Code:
18:30:51.778759 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:26:c7:34:f5:76, length 300, xid 0x91295062, Flags [none]
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Requested-IP Option 50, length 4: 192.168.0.6
	    Hostname Option 12, length 8: "thinkpad"
	    Parameter-Request Option 55, length 17: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
	      NTP
18:30:52.785070 IP (tos 0x0, ttl 128, id 57005, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.1.bootps > 192.168.0.6.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x91295062, Flags [none]
	  Your-IP 192.168.0.6
	  Server-IP 192.168.0.1
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Time-Zone Option 2, length 4: 0
	    Default-Gateway Option 3, length 4: 192.168.0.1
	    TTL Option 23, length 1: 64
	    Lease-Time Option 51, length 4: 3600
	    Server-ID Option 54, length 4: 192.168.0.1
	    Domain-Name-Server Option 6, length 8: 194.168.4.100,194.168.8.100
Mind you that is requesting that IP from an existing lease. How many combinations have you actually tried?

Last edited by acid_kewpie; 06-05-2011 at 01:36 PM.
 
1 members found this post helpful.
Old 06-05-2011, 01:34 PM   #5
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,415

Rep: Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968
Quote:
Originally Posted by doru View Post
If you refer to this line:
Code:
 1253 93310 ACCEPT     all  --  *      *       0.0.0.0/0            93.114.xx.xx        state RELATED,ESTABLISHED
then you should explain why is a package accepted even though it has a destination of 255.255.255.255, when the required destination is 93.114.xx.xx.
Yeah that was confusing me a little, however the starting point for the request is that there is no address on the interface, and in those circumstances I'm not clear how the rules are supposed to be interpreted anyway.
 
Old 06-05-2011, 01:55 PM   #6
doru
Member
 
Registered: Sep 2008
Distribution: Ubuntu 8.04 LTS Server
Posts: 89

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by acid_kewpie View Post
Have you actually looked at the response? Just checking mine, it's actually addressed to the address in the offer itself.

Code:
18:30:51.778759 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:26:c7:34:f5:76, length 300, xid 0x91295062, Flags [none]
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Requested-IP Option 50, length 4: 192.168.0.6
	    Hostname Option 12, length 8: "thinkpad"
	    Parameter-Request Option 55, length 17: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
	      NTP
18:30:52.785070 IP (tos 0x0, ttl 128, id 57005, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.1.bootps > 192.168.0.6.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x91295062, Flags [none]
	  Your-IP 192.168.0.6
	  Server-IP 192.168.0.1
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Time-Zone Option 2, length 4: 0
	    Default-Gateway Option 3, length 4: 192.168.0.1
	    TTL Option 23, length 1: 64
	    Lease-Time Option 51, length 4: 3600
	    Server-ID Option 54, length 4: 192.168.0.1
	    Domain-Name-Server Option 6, length 8: 194.168.4.100,194.168.8.100
Mind you that is requesting that IP from an existing lease. How many combinations have you actually tried?
Please tell me how did you obtain that record. I start tcpdump and then I do dhclient eth0 in another terminal, but I can't see that.

What combinations are you refering to?
 
Old 06-05-2011, 01:58 PM   #7
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,415

Rep: Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968
well I mean how extensive is your testing? I don't know what address i'd expect if it didn't have an IP to request already etc. I'm only testing this against my noddy cable router, not isc dhcpd etc...

I just ran "tcpdump -vn -i wlan0"
 
Old 06-05-2011, 02:27 PM   #8
doru
Member
 
Registered: Sep 2008
Distribution: Ubuntu 8.04 LTS Server
Posts: 89

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by acid_kewpie View Post
well I mean how extensive is your testing? I don't know what address i'd expect if it didn't have an IP to request already etc. I'm only testing this against my noddy cable router, not isc dhcpd etc...

I just ran "tcpdump -vn -i wlan0"
Thank you for your answer. It is clear that dhcp does not follow Wikipedia's description. I did not try many combinations, I have the same address allocated every time through dhcp, and I am connected to a relatively large LAN which is flooding my tcpdump. This is what I got:

Code:
tcpdump -vvn | grep -i dhcp
21:16:47.401380 IP6 (hlim 1, next-header UDP (17) payload length: 99) fe80::c4a4:c1a2:596c:20d7.546 > ff02::1:2.547: dhcp6 solicit (xid=728da8 (elapsed time 6300) (client ID hwaddr/time type 1 time 357520540 6cf04957e2d8)[|dhcp6ext])
21:16:49.003227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:a1:b0:f0:xx:xx, length 300, xid 0x37453e6a, Flags [none] (0x0000)
21:16:49.004430 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328) 93.114.xx.1.67 > 93.114.xx.xx.68: BOOTP/DHCP, Reply, length 300, xid 0x37453e6a, Flags [none] (0x0000)

# The other terminal: 
dhclient3 eth0
There should have been four packets, two out and two in, but we both see only two (I am not sure that the first one is mine; plus, tcpdump only catches what it can.) So this should clarify it all: "And the chaos, who created the chaos? The programmers did." Thanks again.
 
Old 06-05-2011, 02:33 PM   #9
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,415

Rep: Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968
Flicking around briefly I think you're interpreting things incorrectly. As the exchanges we're both seeing are renewals not initial requests, therefore it is a different scenario. The full handshake not appropriate as it already has the information it wants, and just needs to confirm it. So once the server confirms the requested details it doesn't need to hear back again as it's been asked to confirm, not asked for new information.
 
Old 06-05-2011, 02:53 PM   #10
doru
Member
 
Registered: Sep 2008
Distribution: Ubuntu 8.04 LTS Server
Posts: 89

Original Poster
Rep: Reputation: 16
Quote:
Originally Posted by acid_kewpie View Post
Flicking around briefly I think you're interpreting things incorrectly. As the exchanges we're both seeing are renewals not initial requests, therefore it is a different scenario. The full handshake not appropriate as it already has the information it wants, and just needs to confirm it. So once the server confirms the requested details it doesn't need to hear back again as it's been asked to confirm, not asked for new information.
Right, it can be a completely different standard for renewal.

I did this:
Code:
ifdown eth0
ifconfig eth0 up
#now the other terminal
tcpdump -vvn | grep -i dhcp
#now back to the first terminal
dhclient3 eth0
#and I got this: 
tcpdump -vvn | grep -i dhcp
tcpdump: WARNING: eth0: no IPv4 address assigned
21:46:58.003515 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:a1:b0:f0:xx:xx, length 300, xid 0x71534c7f, Flags [none] (0x0000)
21:46:58.004386 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328) 93.114.xx.1.67 > 93.114.xx.xx.68: BOOTP/DHCP, Reply, length 300, xid 0x71534c7f, Flags [none] (0x0000)
It is pretty clear that it does not follow the standard. It could not pass through iptables if it did.

Or maybe they use a different standard, for the case of one single dhcp server in the lan.

Thanks for this.

Last edited by doru; 06-06-2011 at 09:27 AM. Reason: afterthought
 
  


Reply

Tags
iptables


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
DHCP Offer is not a broadcast traffic when using a DHCP Relay, why? jayadhanesh Linux - Networking 1 03-23-2009 09:17 AM
How to select among many dhcp offer sana afsar Linux - Networking 3 07-09-2008 07:41 AM
No dhcp offer on cable modem nx5000 Linux - Networking 6 09-07-2007 05:26 PM
DHCP offer only each 2nd boot hetOrakel Suse/Novell 1 04-19-2005 06:56 PM
DHCP offer packet refused David_Moses Linux - Wireless Networking 2 01-15-2005 07:59 AM


All times are GMT -5. The time now is 08:04 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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration