bootpd problems

Hi there,

Can anyone from QNX confirm that the reported problems with bootpd and
arp have been fixed?

I’m trying to get an x86 board to boot via bootp, but am having no luck.
From observation, the QNX 6.1 machine is receiving the request and
attempting to respond, but the target does not receive the response.
I’ve seen mention of a problem with ARP and some talk of a patched fix
for this.

Any suggestions?

Cheers

Dave

The issue I am thinking of is that at one point, you could not set entries
in the ARP cache. This meant that the bootpd could not unicast back to
the client and needed to broadcast the response. I believe this was added
by 6.1. It would be best to refer to the syslog and the debug option for
bootpd to see if an error is being logged. Is an entry for the client
being created in the arp cache (arp -an)?

Has the client received the boot image file name?

Dave



Dave Edwards <nobody@home.com> wrote:

Hi there,

Can anyone from QNX confirm that the reported problems with bootpd and
arp have been fixed?

I’m trying to get an x86 board to boot via bootp, but am having no luck.
From observation, the QNX 6.1 machine is receiving the request and
attempting to respond, but the target does not receive the response.
I’ve seen mention of a problem with ARP and some talk of a patched fix
for this.

Any suggestions?

Cheers

Dave

Hi Dave,

As far as I can tell, the QNX machine fails to set the ARP entry. I’ve
managed to get the target board to bootp using some windows shareware
software, but I’d like to get QNX running.

I’ve got bootpd set up with debug and this seems to show that the system
recognises the request, identifies the hardware as being one of the
known system, then it attempts to find the file and reports on the file
size, then it starts all over again.

When I check the ethernet diagnostic leds, I believe that they are
showing a lack of response to the initial bootp request.

As an aside, I have just discovered that there is a limit of around 500K
on the size of the bootp image that can be sent, do you know of any way
to increase this? I’ve heard mention of secondary loaders, but cannot
find anything suitable.


Thanks in advance

Dave


Dave Brown wrote:

The issue I am thinking of is that at one point, you could not set entries
in the ARP cache. This meant that the bootpd could not unicast back to
the client and needed to broadcast the response. I believe this was added
by 6.1. It would be best to refer to the syslog and the debug option for
bootpd to see if an error is being logged. Is an entry for the client
being created in the arp cache (arp -an)?

Has the client received the boot image file name?

Dave



Dave Edwards <> nobody@home.com> > wrote:

Hi there,


Can anyone from QNX confirm that the reported problems with bootpd and
arp have been fixed?


I’m trying to get an x86 board to boot via bootp, but am having no luck.
From observation, the QNX 6.1 machine is receiving the request and
attempting to respond, but the target does not receive the response.
I’ve seen mention of a problem with ARP and some talk of a patched fix
for this.


Any suggestions?


Cheers


Dave

Dave Edwards <nobody@home.com> wrote:

Hi Dave,

As far as I can tell, the QNX machine fails to set the ARP entry. I’ve
managed to get the target board to bootp using some windows shareware
software, but I’d like to get QNX running.

I’ve got bootpd set up with debug and this seems to show that the system
recognises the request, identifies the hardware as being one of the
known system, then it attempts to find the file and reports on the file
size, then it starts all over again.

How many -d options are you passing to bootpd? Try passing 5 and more debug
should be logged. Looking at the cvs logs, the arp code should be present.
Having more debug options increases the debug level and bootpd should report
that it is going to modify the arp cache whether successfull or not. Could
you also include the output from netstat -in.



When I check the ethernet diagnostic leds, I believe that they are
showing a lack of response to the initial bootp request.

Hopefully more debug might give an impression of what happened. The
file size messages you are referring to occur just before the function
to send the reply.


As an aside, I have just discovered that there is a limit of around 500K
on the size of the bootp image that can be sent, do you know of any way
to increase this? I’ve heard mention of secondary loaders, but cannot
find anything suitable.

This limit can vary from rom to rom but not very much. PXE is another option
but we don’t have a server solution for this right now.

Dave


Thanks in advance

Dave



Dave Brown wrote:
The issue I am thinking of is that at one point, you could not set entries
in the ARP cache. This meant that the bootpd could not unicast back to
the client and needed to broadcast the response. I believe this was added
by 6.1. It would be best to refer to the syslog and the debug option for
bootpd to see if an error is being logged. Is an entry for the client
being created in the arp cache (arp -an)?

Has the client received the boot image file name?

Dave



Dave Edwards <> nobody@home.com> > wrote:

Hi there,


Can anyone from QNX confirm that the reported problems with bootpd and
arp have been fixed?


I’m trying to get an x86 board to boot via bootp, but am having no luck.
From observation, the QNX 6.1 machine is receiving the request and
attempting to respond, but the target does not receive the response.
I’ve seen mention of a problem with ARP and some talk of a patched fix
for this.


Any suggestions?


Cheers


Dave