views:

352

answers:

2

Hello

I have 2 boxes: - an embedded device (ARM Omap with linux) which I'll call "Omap". - a PC (can either be Windows or linux).

Scenario 1

Both boxes are in the same network (example: my office).
The Omap gets its address from a DHCP server (ex: 192.168.10.110). The PC has always the same address (ex. 192.168.10.104).
I can successfully exchange UDP broadcast packets on any port.
Success.


Scenario 2

The 2 boxes are in a network withOUT a DHCP server.
The PC has a static IP address (example: 10.10.10.20).
The Omap boots, looks for a DHCP server, doesn't find it, and is in what I call "bad IP address" state.
Now... Broadcasting UDP packets from the Omap works: the PC can see them.
The opposite doesn't work: UDP packets broadcasted by the PC are not seen by the Omap. I am using Wireshark on another PC to verify that the packets are being sent.
Failure.

I tried to change the Omap ip address (with ifconfig)... no luck.

What am I missing?

To complete the picture, when the Omap is in Scenario 2, if I run udhcpc ... it can communicate with the DHCP server and get an IP address. I also see the packets with Wireshark. So this means that the DHCP client is able to broadcast UDP packets. (Yes, I tried to use DHCP ports 67/68 but it doesn't work).

I am using Boost C++ Asio UDP sockets. Specifically, I took the multicast examples and changed them to do broadcasting.

Any help is appreciated.

Thanks, Benedetto

PS: Some clarifications.

The Omap device is an embedded device and my objective is that the customer should not have to set its IP address on the field. That's why I am exchanging broadcast packets with the PC, to get a "good" IP address from my other software running on a PC (which knows what the current subnet is, even in a network with static IP addresses and no DHCP server).

Esseentially I implemented a very simple DHCP protocol. The PC could listen to the packets broadcasted by the Omap, but not vice versa.

A: 

A few thoughts...

1) ifconfig eth0 -- Is the interface up, does it have an IP address, a suitable netmask, etc?

2) Routing -- Is it configured properly? (Netstat -r or route) (This can be an issue if the IP addresses are on different un-routed subnets, depending on the netmask.)

3) Firewall -- I can't tell you how many time's I've run into firewall issues. Verify it's not being stopped there.

4) Try tcpdump directly on the respective systems -- what does it show? What is getting through?

5) Can you ping from one system to another? (ICMP may have different rules than UDP.)

(I would bet on the down interface, different subnet blocked by netmask, or no route to host problems first.)

Mr.Ree
1) interface is up.2) netstat -r Destination Gateway Genmask Flags MSS Window irtt Iface10.0.0.0 * 255.0.0.0 U 0 0 0 eth0 3) I don't think there's any firewall. <br/>4) I tried socat on the Omap: doesn't see the packets. The PC does. 5) Ping gives "Network is unreachable".
Benedetto
A: 

If you set an IP address with ifconfig, that's likely not going to be enough. Usually, you must also configure the routing table, which usually consists of adding two routes: One saying that "this network is attached at eth0" and one saying "this is the default gateway". (The latter is not strictly required.)

"Network is unreachable" - I'm assuming you tried to ping the PC from the OMap? If your PC was 192.something.something.something, and your "OMap" has the routing table your comment:

Destination  Gateway  Genmask    Flags  MSS  Window  irtt  Iface
10.0.0.0     *        255.0.0.0  U      0    0       0     eth0

...then it won't be able to send. That routing table will only work if you try to send things to 10.something: that's the only route it knows. If you're not running a 10.0.0.0/8 network, then that route is wrong.

Look up some material on routing tables, IP addresses, etc. if you want to do this. Although, if you want to just have the average person "plug it in" - they're going to be running DHCP - what's so wrong with that? You can't just pick an IP address on a network without some form of mediation: Either a human mediates, and sets it manually, or you use something like a DHCP server. Otherwise, you could be picking somebody else's address. Also, you need to know whether you're on a 10.0.0.0/8 network, a 192.168.0-255.0/8 network, some other LAN, or the Internet... something DHCP does for you...

Thanatos
Thanks Thanatos.I don't know much about subnets and routes... (as you have probably understood) but I realized that the route table looked not adequate.I cannot give more details, but in many circumstances there will be no DHCP server. If a DHCP client can send and receive broadcasting messages from a 10.0.0.0/8 network... so could my software.Digging a little bit in the DHCP client code I see that it uses raw sockets. That seems a viable solution.THhnks again!
Benedetto