streams example driver needs double ifconfig request

[Allan Morton]

I've integrated the UX 11.0 example enet network device driver into my B180 and replaced the backend lower driver with another packet source.

My rather stange problem is that after running ifconfig for the first time after a reboot (or doing it via netconf) to enable the interface, when messages are passed upstream via streams_put(), the messages are seen in the driver and STREAMS nettl trace but never get any further into the network stack. Pings etc seem to be passed into the driver fine.

However, when ifconfig is run a second time (with just the IP address) everything works fine with 2-way traffic.

I've tried ifconfig plumb and then ifconfig IP but it seems to need the second ifconfig IP for the streams plumbing to be fully enabled.

The only error I can detect is when ifconfig plumb is run, the example DLPI IOCTL function gets a command of 0x20006b33 which it rejects as the stream is not attached (bound) at the time it is issued.

Any ideas or should I just run ifconfig twice!?

[rick jones]

A double ifconfig should not be required.

A couple things to do:

1) try the example driver with no changes and see if it requires a double ifconfig.

if not, then take a tusc trace of an ifconfig against a driver that does not require double ifconfig and compare that with the tusc trace of the ifconfig of your driver.

i do not think there should be any errors in the DLPI IOCTLs

[Allan Morton]

Thanks Rick,

I've tried tusc on both ifconfig calls (in attachment if interested), but the only things I can see strange is that the first one does ioctls on /dev/dlpi rather than my dlpi driver and that I_PLINKs on /dev/ip appear to fail (if I'm reading it right).

The second ifconfig is similar but without the streams plumbing, however incoming traffic flows straight after using it (its a lot of bootp requests which can be seen in the STREAMS nettl trace but then seem to get lost until the second ifconfig).

[Allan Morton]

Hi,

I've tracked the problem down to the SET_NOLOOPBACK IOCTL in the driver.

When ifconfig is first run it sends a SET_NOLOOPBACK IOCTL to the driver to disable the looping back of outgoing broadcast messages.

However, the messages I am trying to pass through the driver are all bootp requests from another device which are sent to the broadcast address. Therefore the driver eats all these messages due to the loopback flag being set.

When ifconfig is run again, the NOLOOPBACK flag is reset (as part of initialising the internal structures), the IOCTL is not re-sent, so all my traffic starts to work.

I think this explains what is happening. What should be the correct fix, disable the NOLOOPBACK setting operation?