Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
- Subject: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
- From: Hostile Fork <email@hidden>
- Date: Tue, 29 Jan 2008 23:57:17 -0800
Hello Mac Network programmers...!
I am porting a WinSock DHCP-like server to OS/X, and have run into a
wall. After using packet sniffers I've found a smoking gun that OS/X
may be ignoring broadcast UDP packets that are sent from the serviced
network to 255.255.255.255 to the serviced port #8567. (FYI: This
machine has two network cards, and the devices that are making DHCP
requests are connected on a network through the second card which has
a static IP address... the first card is used for plain ol' internet
access.) It's a little complicated, but I'll point out that send()s
to that static IP subnet are seeming to work and get a reaction, so
the connection is at least somewhat "alive".
The evidence that I have that packets are being ignored is that
running netcat directly to the IP address with a UDP packet unblocks
my recvall() call, while packets sent to the same port but broadcast
to 255.255.255.255 from 0.0.0.0 will not unblock the recvall(). The
packet sniffer shows that the mac is receiving these broadcast
packets. And curiously, it works to run the Windows version of the
DHCP server under VMWare if the two network cards are bridged as
virtual devices for Windows. Under VMWare, Windows will unblock the
recv call in response to the 255.255.255.255 message that shows up in
the sniffer!
The OS/X firewall is turned off and there is no other firewall running
that I know of, so that isn't likely to be the problem the way it was
here:
http://lists.apple.com/archives/Macnetworkprog/2003/Jun/msg00023.html
I've seen other people having this issue, and read this technical note
which they were referred to:
http://developer.apple.com/qa/nw/nw53.html
I'm using Berkeley sockets API, so the best I can say is that my
bind() call is using INADDR_ANY, which is 0.0.0.0. I also took the
precaution of adding SO_BROADCAST to the sockoptions, even though it
wasn't in the Windows code and I'm not certain it affects receivers.
I added it anyway because this UNIX page says that when SO_BROADCAST
is enabled, "datagram sockets receive packets sent to a broadcast
address and they are allowed to send packets to a broadcast address.":
http://savannah.nongnu.org/task/?6995
I'm kind of at a loss for what I might test next...this is pretty much
blocking me, no pun intended. Does anyone have any ideas? Something
I could try to generate more information? I've attached some data
about the ignored packet, if that helps. Thanks muchly...!
[HERE'S THE PACKET THAT WOULD NOT BUMP THE recvall() OUT OF BLOCK
STATE, EVEN THOUGH NETCAT OF UDP PACKETS TO PORT 8567 ON THIS MACHINE
WORKED FINE]
Frame 5 (346 bytes on wire, 346 bytes captured)
Arrival Time: Jan 29, 2008 20:31:36.492649000
Time delta from previous packet: 4.249231000 seconds
Time since reference or first frame: 12.623832000 seconds
Frame Number: 5
Packet Length: 346 bytes
Capture Length: 346 bytes
Frame is marked: False
Protocols in frame: eth:ip:udp:data
Coloring Rule Name: UDP
Coloring Rule String: udp
Ethernet II, Src: SystemAA_00:1f:a2 (00:00:37:00:1f:a2), Dst:
Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/
broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address
(this is NOT the factory default)
Source: SystemAA_00:1f:a2 (00:00:37:00:1f:a2)
Address: SystemAA_00:1f:a2 (00:00:37:00:1f:a2)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Frame check sequence: 0x22b03d15 [correct]
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 328
Identification: 0x0001 (1)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x79a5 [correct]
Good: True
Bad : False
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 8568 (8568), Dst Port: oap-admin
(8567)
Source port: 8568 (8568)
Destination port: oap-admin (8567)
Length: 308
Checksum: 0x42e8 [correct]
Good Checksum: True
Bad Checksum: False
Data (300 bytes)
0000 ff ff ff ff ff ff 00 00 37 00 1f a2 08 00 45 00 ........7.....E.
0010 01 48 00 01 00 00 40 11 79 a5 00 00 00 00 ff ff .H....@.y.......
0020 ff ff 21 78 21 77 01 34 42 e8 01 01 06 00 e9 73 ..!x!w.4B......s
0030 ff a2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 37 00 1f a2 00 00 00 00 ........7.......
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 63 82 53 63 35 01 01 37 09 36 ......c.Sc5..7.6
0120 33 3a 3b 01 03 06 0f 1c 39 02 02 40 ff 00 00 00 3:;.....9..@....
0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 00 00 00 00 00 00 22 b0 3d 15 ......".=.
---
http://hostilefork.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden