1

I have an application that opens a socket on port 4444 to a device (/dev/linkToDevice). The "linkToDevice" is a link to ttyUSB0. The application is a c++ program of which is now a daemon and runs at boot up. The daemon runs regardless of network. So when the linux box is booted, and there is not network, the daemon starts immediately and while there is still no network, I can communicate just fine (telnet localhost 4444). But, when I plug in a network cable, or dhclient determines there is no DHCP and leases me a default ip address, or I just simply give it an ip interface, I can no longer communicate. I can, however, still open the telnet connection, I just get no response when I query for one.

I use 0.0.0.0 as the ip to open the socket on (signifying any ip address). I don't feel like it is a code problem.

The odd part to me is that after I can no longer communicate, if I restart the daemon, everything works great, which is expected. But, when I unplug the network, or unconfigure the interface, or do a sudo /etc/init.d/networking restart, or any sort of bringing the network down and back up again, through that entire process I never lose communication to the device. So the problem ONLY happens when I boot the machine with no network to begin with, and then I all of a sudden get a network. Any thoughts as to why this only happens at boot up?

Improve this question
8
  • Oh and when I cant communicate with the device via telnet, I tried to echo a command to the device itself and get a response of "Device or resource busy." But I assume this is because my program is still running and supposedly is communicating with the device. Commented Mar 28, 2013 at 20:32
  • Sounds like time for an strace Commented Mar 28, 2013 at 20:34
  • Yea I have heard of that. I tried it for a bit, but I dont seem to see what is going on from that. Commented Mar 28, 2013 at 20:45
  • Does the problem persist when you go straight to ttyUSB0? I'm not quite sure of your use case. Can you give an example of how you're opening the socket on both sides - either with a code snippet or equivalent MWE (maybe something with socat and telnet)? Commented Mar 28, 2013 at 21:02
  • The problem still persists when accessing the device directly. As far as the socket goes, it is a pretty simple server and client connection. Plus, the nature of the problem tells me that the code is fine, seeing as the program runs and is fine except for that one situation. I can tell you this, the device is a ttyUSB0 onboard device that I open, which returns a file descriptor. I then open a socket with that file descriptor on port 4444 using 0.0.0.0 as the ip. This enables me to telnet to localhost (or the ip of machine) on 4444 to send and receive commands. Commented Mar 28, 2013 at 21:11

1 Answer 1

Reset to default
0

"Mainly I need to know the difference between obtaining an eth0 interface for the first time after booting with no network, and restarting the network to re-obtain an eth0 interface after one used to be previously established. The code works for the latter."

Before you approach it that way, rule out the shenanigans of the high level networking service ("NetworkManager"). I always disable it and just stick commands into the boot process at some appropriate point (eg, ifconfig eth0 up && dhclient eth0), then manually run other simple scripts to switch from eth to wifi etc. NetworkManager is a giant octopus of automation which is no doubt very useful if you do not know what an "interface" is or are driving around with a laptop trying to roam across wifi networks, but if you prefer to just turn things on and off on your own, it can make irritating and mysterious choices. I admit to having never learned how to configure it on the premise that a high level tool which is harder to use to perform a specific task than the low level tools it "manages" is not an appropriate tool in the context of that task.

In case this isn't clear:

when I unplug the network, or unconfigure the interface, or do a sudo /etc/init.d/networking restart

/etc/init.d/networking implies a .deb system (.rpm ones use /etc/init.d/network). Disable this (and/or the corresponding upstart service on systems that use upstart) so it does not run at boot and replace it with with whatever simple commands you need to access your network somewhere late in the boot process. If it exists, I also comment out everything in /etc/network/interfaces except lo.

I would not normally consider this good advice to hand out to other users, but your problem to me just screams, "betcha it's that giant octopus" -- which you do need to rule that out before you look behind it.

Improve this answer
8
  • Thank you for your answer. I will get on this asap. Question: what if I am not just trying to turn on/off the network. I want to be able to let an interface be found automatically in the case of DHCP. So it would be nice to have NetworkManager running in the beginning until it times out, according to the dhclient. Where the issue really hits is in the case of a Cisco router vs Netgear. Cisco takes about 2 minutes to boot, which is much longer than it takes the machine to boot. Netgear boots in 30 seconds or less. Unfortunately we have to use both Cisco and Netgear. Commented Apr 2, 2013 at 13:09
  • The other issue is: dhclient needs to have a timeout in it long enough to wait for DHCP to activate first before it throws an ip. Since dhclient is called in the beginning already, what would "ifconfig eth0 up && dhclient eth0" really accomplish? Commented Apr 2, 2013 at 13:14
  • @Zonxwedop : What "beginning" are you talking about? By disabling NetworkManager et. al., I meant that you completely arrange everything yourself, not that you leave some service running which starts dhclient "in the beginning". The interface needs to be up before you run dhclient, or dhclient will not accomplish anything. Those are two basic commands (ifconfig then dhclient) that will get a linux system onto a network. If you have more complex needs you want to automate that's a separate question, but in terms of diagnosing your problem, start with what's basic. Commented Apr 4, 2013 at 11:06
  • As far as I know, dhclient runs irregardless of a network interface. All I have done is set a lease and a timeout to where when the timeout expires, and there is no network interface given by dhcp, then the dhclient will lease its address. This is so if we boot the machine in an environment where we dont have a network but we want a network eventually, we can set one up remotely because we know what leased address is on the machine. The "beginning" I am talking about is when I boot the machine. I am looking into NetworkManager right now Commented Apr 8, 2013 at 12:54
  • If dhclient is running at the beginning, it is because a userspace service (again: probably the ubiqitous NetworkManager) started it explicitly during boot. It cannot just start spontaneously for no reason. So if it's running and you didn't do it, something is trying to manage your network connection. That something might also be causing your problem (I can't say for sure, but you do need to rule it out by temporarily configuring the system to not automate handling of dhclient, etc.) Commented Apr 8, 2013 at 13:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.