search for: devst_error

...random UDP packets we don't care about and errors. After the patch, either a packet is a DHCP/BOOTP packet or packet_recv() exits with an error. This breaks ipconfig on big, noisy LANs where random UDP traffic can arrive before the DHCP reply and throw the device into DEVST_ERROR state. This fixes http://bugs.debian.org/552554 Tested-by: Michael Prokop <mika at debian.org> Signed-off-by: maximilian attems <max at stro.at> diff --git a/usr/kinit/ipconfig/bootp_proto.c b/usr/kinit/ipconfig/bootp_proto.c index 42dfad3..baf9d3e 100644 --- a/us...

This patch fixes a bug on systems with multiple connected network devices. As packet_peek uses all devices to receive data instead of a specific device. As the return value was never reset it was possible that packets from other devices were returned by packet_peek. That means that the ifindex did not match any ifindex of the specified devices the packet was never removed and packets for the

...story show I had been sceptic to that monster patch, but several users had pushed for it, see: http://bugs.debian.org/511959 > After this commit, if a random UDP packet comes in before the expected > DHCP reply packet_recv() will exit with an error and the interface will be > sent into DEVST_ERROR instead of just ignoring this packet. On busy LANs, > ipconfig can go through this loop several times. > > JB. as mika is currently on vacation after Debconf. I will look into the issue and see if said patch resolves his testcase which is nicely layed out in http://bugs.debian.org/55255...

Hello, I found a bug in ipconfig and I'm sending a proposed patch for it. I've only seen it happen in 2 dhcp-server environments. Scenario: ipconfig sends a DHCP_DISCOVER, server A answers with a DHCP_OFFER, server B answers with a DHCP_OFFER, ipconfig sends a DHCP_REQUEST for server A, ipconfig accepts the DHCP_OFFER from server B instead of DHCP_ACK from server A. <== BUG The reason

...all those are used in switch() statements in main.c, where -1 and strictly positive values are checked for, but not 0. Hence the attached patch: 0001-trivial.patch. I guess one could consider it a special case that might deserve a DEVST_SOFTERROR state, which could have a shorter retry delay than DEVST_ERROR. Especially true for some setups with a hundred machines or more, it'd be quite a PITA to wait 10 seconds for a retry where only a couple of machines will complete the DHCP handshake. Not to mention the default timeout that'll bite. That's why I'm proposing a second patch: 0002-intr...

Hi, ipconfig is used in ltsp (thin clients) initramfs. Some of the users have to have 2 dhcp servers in ltsp environments, so they hit on this problem: The first dhcp request is from the pxe rom boot code. This code ignores any dhcp offers that don't have a filename field. So they always get the correct address, from the ltsp server. The second dhcp request (in initramfs) is done by

...(dev)) @@ -118,8 +124,10 @@ } } -static void process_receive_event(struct state *s, time_t now) +static int process_receive_event(struct state *s, time_t now) { + int handled = 1; + switch (s->state) { case DEVST_BOOTP: s->restart_state = DEVST_BOOTP; @@ -173,8 +181,12 @@ case DEVST_ERROR: /* error occurred, try again in 10 seconds */ s->expire = now + 10; + default: + handled = 0; break; } + + return handled; } static void process_timeout_event(struct state *s, time_t now) @@ -231,20 +243,23 @@ static struct state *slist; -static void do_pkt_recv(int pkt_fd,...

...ime_t now) { int handled = 1; @@ -214,6 +219,10 @@ static int process_receive_event(struct state *s, time_t now) break; } break; + + default: + handled = 0; + break; } switch (s->state) { @@ -224,9 +233,6 @@ static int process_receive_event(struct state *s, time_t now) case DEVST_ERROR: /* error occurred, try again in 10 seconds */ s->expire = now + 10; - default: - DEBUG(("\n")); - handled = 0; break; } @@ -288,23 +294,30 @@ static void process_timeout_event(struct state *s, time_t now) static struct state *slist; struct netdev *ifaces; +/* + * Retu...