Services

Hi All,

I am seeing a quirk I could do with being explained; Any takers?

The set up is as follows:
m0n0 <--> Wireless Access Point <--> Wireless AP Client <--> LAN <--> PC_1
                                <--> PC_2 (with wireless nic)

m0n0 is setup as a DHCP server, and all of the devices are on the same LAN: 192.168.0.0/24.
If PC_1 is statically configured for 192.168.0.123, then all works well.
If PC_1 is set to aquire it's IP via DHCP then there is a delay before a DHCP Discover is responded to.  Upto 5 DHCP Offers go unanswered.
If another device (PC_2) connects via wireless it gets it's DHCP Discover answered with a DHCP offer instantly.

In detail on PC_1 using wire shark from bringing the eth0 up:
00 >> DHCP Discover
05 >> DHCP Discover
15 >> DHCP Discover
30 >> DHCP Discover
(PC gives up and used alternative IP)
60 >> Gratuitous ARP for 169.254.251.71
61 >> Gratuitous ARP for 169.254.251.71
62 >> Gratuitous ARP for 169.254.251.71
65 >> DHCP Discover
66 >> DHCP Offer
66 >> DHCP Request
66 >> DHCP ACK

On PC_2 the following is seen from bringing ath0 up:
00 >> DHCP Discover
00 >> DHCP Offer
00 >> DHCP Request
01 >> DHCP ACK

Any idea why m0n0 only responds to DHCP Discover after the client has broadcast an ARP notice?  Could this be a limitation in the wireless AP or AP client (both DWL-7100AP devices...)

I will go off and tap the ethernet to the m0n0wall to see if the initial DHCP Discover message are getting through, but anyone with an insight would be great...

I had a similar problem a while back but could find no cure myself or by searching the forums so now running a fixed IP and all seems well since.

There do seem to be quite a few, seemingly unresolved, posts about DHCP problems across bridged interfaces.

This problem has just hit me again on a laptop I rarely use. I'm currently running 1.8.0b500 but believe this may affect other versions so leaving here for the time being. I have public IPs and IPv6 configured, Alix 2d3, Atheros WLAN card (bridged to LAN).

The laptop gets correct address from mono via WLAN at boot but when DHCPREQUESTs are issued later there is no response whatsoever. Laptop syslog shows line after line of DHCPREQUESTs

I have set mono to log all rules but nothing relevant appears at all in Firewall or in DHCP logs.

I don't believe this is expected behaviour but may be mistaken.

Issuing

Code:

dhcping -s 'mono' -r -v

generates

Code:

no answer

and nothing in mono logs.

Issuing

Code:

dhcping -s 255.255.255.255 -r -v

generates

Code:

Got answer from 'mono'
received from 'mono', expected from 255.255.255.255
no answer

and

Code:

dhcpd: DHCPNAK on 0.0.0.0 to 00:00:00:00:00:00 via vr0
dhcpd: DHCPREQUEST for 0.0.0.0 from 00:00:00:00:00:00 via vr0: wrong network.

in mono DHCP logs

I am also seeing much the same on this desktop (bridged with LAN but wired), which I thought I'd set static but is also DHCP. A server also on WLAN is fine, static address with no DHCP - this was machine originally giving me problems.

Wireshark is seeing requests but no responses from mono.

Should I expect responses to DHCPREQUESts, or at least something in the mono logs?

Any suggestions as to how I can find out where packets seem to be disappearing?


Later, after a lot of searching and reading...

It seems this is expected behaviour after all, AIUI the server is not required to reply until the lease expires - which it does. The DHCPREQUEST log messages are just noise, there does not appear to be an easy way of reducing their frequency on the client.