Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - IO-PKT send a packet on startup.: Page 1 of 2 (33 Items)
   
IO-PKT send a packet on startup.  
Hey

When I starting io-pkt-v4-hc with my mpc85xx driver.
I see i nicinfo that one packet has been send.

The package is a ARP packet. Is it possible to disable the driver or stack so it's not sending this frame?

I had attached the slogger log.


Attachment: Text slogger 24.62 KB
Re: IO-PKT send a packet on startup.  
On 15/02/10 06:15 AM, Lasse Skov wrote:
> Hey
>
> When I starting io-pkt-v4-hc with my mpc85xx driver.
> I see i nicinfo that one packet has been send.
>
> The package is a ARP packet. Is it possible to disable the driver or stack so it's not sending this frame?
>    
What ARP packet is being sent? Is it a gratuitous ARP?
/P
RE: IO-PKT send a packet on startup.  
> Is it a gratuitous ARP?

Almost certainly.  I think he wants to turn off
the initial gratuitous ARP when the TCP/IP stack
starts.  I'm not sure that's configurable from
the command line.

--
aboyd
Re: IO-PKT send a packet on startup.  
>> Is it a gratuitous ARP?
>>      
> Almost certainly.  I think he wants to turn off
> the initial gratuitous ARP when the TCP/IP stack
> starts.
There's a gratuitous ARP when the IP address is configured on an interface.
>    I'm not sure that's configurable from
> the command line.
>    
It is not configurable AFAIK.

/P
Re: IO-PKT send a packet on startup.  
Hmmmm... okay..

Could i disable this in the io-pkt stack on my own?
And if where?

/LSkov
Re: IO-PKT send a packet on startup.  
On 16/02/10 10:46 AM, Lasse Skov wrote:
> Hmmmm... okay..
>
> Could i disable this in the io-pkt stack on my own?
> And if where?
>    
You should probably look at sys/netinet/if_arp.c arp_ifinit().

At your own risk of course :-)

/P
Re: IO-PKT send a packet on startup.  
Thanks... 

I see that this arp packet only sendt if the IPAddress is not zero.

So I tried to set the ip to null and now the tsec controller is not send any packages out.
This is good enough for testing my hardware.

If I download hole the core networking and from the foundry, and try to build it i also got a error.
Is there some special things I need to do before i try to build it on my XP machine?

/LSkov
Re: IO-PKT send a packet on startup.  
On 16/02/10 11:42 AM, Lasse Skov wrote:
> Thanks...
>
> I see that this arp packet only sendt if the IPAddress is not zero.
>
> So I tried to set the ip to null and now the tsec controller is not send any packages out.
> This is good enough for testing my hardware.
>    
Ok, great. Yes, as I wrote before "There's a gratuitous ARP when the IP 
address is configured on an interface." so if you assign NULL then it 
won't be sent.

> If I download hole the core networking and from the foundry, and try to build it i also got a error.
> Is there some special things I need to do before i try to build it on my XP machine?
>    
Have a look at the builds forum for the latest and greatest on that.

Lycka till! ;-)
/P
Re: RE: IO-PKT send a packet on startup.  
Are you aware of whether it is possible to disable it somehow?

Another thing is that I can see that some data has been send on both controllers.
This is monitored in nicinfo.

But if I set a computer on the tsec0 controller and monitor the data with a tcpdump I cant monitor anything.
How can this be possible?

Anyone have an idea why this package does not come out through the PHY, and into the contorller?

/LSkov
Re: IO-PKT send a packet on startup.  
On 16/02/10 10:42 AM, Lasse Skov wrote:
> Are you aware of whether it is possible to disable it somehow?
>    
Not without code changes in the stack.

Or, perhaps some clever default pf rules might work. Just an idea, I 
haven't tried it. And maybe pf is not feasible for your situation anyways.

/P
RE: RE: IO-PKT send a packet on startup.  
> whether it is possible to disable it somehow?

The source to the stack is on the foundry, so if you
want something different than standard ARP, you can
modify it to do whatever you want.

> why this package does not come out through the PHY

Possibly the link auto-negotiation had not yet completed?

We have seen this before - with DHCP and another driver.

--
aboyd
Re: RE: RE: IO-PKT send a packet on startup.  
I am seeing this on a driver I am currently trying to do, it seems it is related to auto-negotiation not completed. One 
thing I am clear is that if the auto-negotiation is not complete, the interface should be in LINK_DOWN state, why the 
stack is still sending packets down?

RE: RE: RE: IO-PKT send a packet on startup.  
What I was referring to is when the hardware reports
that the link is up - fooling the software - but it 
really isn't ... transmissions immediately after the
link up are lost, but if you wait a couple more seconds
after the auto-negotiation has supposedly completed,
then the packets tx works successfully.

--
aboyd
Re: RE: RE: RE: IO-PKT send a packet on startup.  
It's not the hardware reporting the link up,
after I do a 'dhcp.client'

The driver's ioctl call is called, which is a SIOCSIFADDR, and goes to 
ether_ioctl call, since the driver is not handerling it. By looking at the ether_ioctl call implementation, 
	case SIOCSIFADDR:
   1684 		ifp->if_flags |= IFF_UP;

Then it call the if_init
 		default:
   1713 			if ((ifp->if_flags & IFF_RUNNING) == 0)
   1714 				error = (*ifp->if_init)(ifp);
   1715 			break;

This is where it flip the IFF_UP bit? Is this expected? At that time of course the Link is not UP. Do I need to do 
something extra to explicitly clear the IFF_UP bit in the init call? I've checked few drivers, don't seem to see this 
being cleared in init call. Am I miss something?

RE: RE: RE: RE: IO-PKT send a packet on startup.  
If you look at the end of any devnp driver _init()
function, you will see it set the IFF_RUNNING flag,
which is how it communicates to the stack that it's
up.

However, given that the PHY has just been reset in
the phy init function just above, that almost certainly
restarts the auto-negotiation which is going to take
2 or 3 seconds to complete.

If you look at the ep93xx driver (which I wrote not
too long ago) I tried to address this in the _start
transmit packet function:

http://svn.ott.qnx.com/view/product/trunk/lib/io-pkt/sys/dev_qnx/ep93xx/
transmit.c?revision=234104&view=markup

If the IFF_RUNNING flag wasn't set, or the NIC_FLAG_LINK_DOWN
bit was set in the (legacy) cfg->flags, no transmission of
packets was attempted - the packet was left queued.

--
aboyd
Re: RE: RE: RE: IO-PKT send a packet on startup.  
There isn't a clear concensus as to whether
or not IFF_RUNNING means the link is up
or not.

-seanb

On Tue, Feb 16, 2010 at 03:56:06PM -0500, Andrew Boyd wrote:
> 
> If you look at the end of any devnp driver _init()
> function, you will see it set the IFF_RUNNING flag,
> which is how it communicates to the stack that it's
> up.
> 
> However, given that the PHY has just been reset in
> the phy init function just above, that almost certainly
> restarts the auto-negotiation which is going to take
> 2 or 3 seconds to complete.
> 
> If you look at the ep93xx driver (which I wrote not
> too long ago) I tried to address this in the _start
> transmit packet function:
> 
> http://svn.ott.qnx.com/view/product/trunk/lib/io-pkt/sys/dev_qnx/ep93xx/
> transmit.c?revision=234104&view=markup
> 
> If the IFF_RUNNING flag wasn't set, or the NIC_FLAG_LINK_DOWN
> bit was set in the (legacy) cfg->flags, no transmission of
> packets was attempted - the packet was left queued.
> 
> --
> aboyd
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post47456
> 
RE: RE: RE: RE: IO-PKT send a packet on startup.  
> whether or not IFF_RUNNING means the link is up or not.

The if_up utility can get that information with the "-l"
option.  Note that all of the devnp (io-pkt) drivers 
have bsd_media.c support for link media via ifconfig -v
which uses the driver ioctl to get/set link state.

--
aboyd
Re: IO-PKT send a packet on startup.  
>> whether or not IFF_RUNNING means the link is up or not.
>>      
> The if_up utility can get that information with the "-l"
> option.  Note that all of the devnp (io-pkt) drivers
> have bsd_media.c support for link media via ifconfig -v
> which uses the driver ioctl to get/set link state.
>
>    
That can help a script to launch the DHCP client only after link is up. 
But it doesn't help stack internals (like DAD, see my other email) and 
it doesn't help at all if if_up uses routing sockets to implement '-l' 
(because routing socket link state may bounce several times, se y other 
email).

/P
RE: IO-PKT send a packet on startup.  
> > The if_up utility can get that information 
> > with the "-l" option.  
>
> launch the DHCP client only after link is up. 

I might mention that the shim supports the 
SIOCGIFMEDIA ioctl, hence "ifup -l en0" 
should work even with io-net drivers, in
addition to the native devnp io-pkt drivers.

--
aboyd
Re: IO-PKT send a packet on startup.  
>>> The if_up utility can get that information
>>> with the "-l" option.
>>>        
>> launch the DHCP client only after link is up.
>>      
> I might mention that the shim supports the
> SIOCGIFMEDIA ioctl, hence "ifup -l en0"
> should work even with io-net drivers, in
> addition to the native devnp io-pkt drivers.
>    
AFAIK that state flip/flops together with if_link_state_change().
/P
RE: IO-PKT send a packet on startup.  
Re: IO-PKT send a packet on startup.  
I am an electrical engineer after all :-)

This isn't what we're talking about here though. We're talking about 
auto-negotiation (a protocol) coming to a concluding state and the link 
layer informing the stack about it being done (not prematurely doing it 
at each state it transitions through along the way).

/P
RE: IO-PKT send a packet on startup.  
Hi Guys,

I just cudnt stop myself jumping in :-)
AFAIK, only completing autoneg wouldn't be sufficient in this case.
MAC settings needs to be adjusted according to PHY autonegotiation
results, otherwise MAC and PHY would work in mismatch scenario.
In MPC85XX family (should be the case with others as well), this is
beautifully handled by _speeduplex() functions (One 'd' is missing
here), which are invoked by MDIO library after completing autoneg or
link speed changes.

I think the safest would be to enable transmission of packets from stack
only after this function has been called for the first time.

BR,
Akash Goswami

-----Original Message-----
From: Patrik Lahti [mailto:community-noreply@qnx.com] 
Sent: Thursday, February 18, 2010 1:30 AM
To: drivers-networking
Subject: Re: IO-PKT send a packet on startup.

I am an electrical engineer after all :-)

This isn't what we're talking about here though. We're talking about
auto-negotiation (a protocol) coming to a concluding state and the link
layer informing the stack about it being done (not prematurely doing it
at each state it transitions through along the way).

/P




_______________________________________________

Networking Drivers
http://community.qnx.com/sf/go/post47583
RE: IO-PKT send a packet on startup.  
> enable transmission of packets from stack only after 
> this (MDI callback) function has been called for the 
> first time

If you look at some nicinfo output with the driver
verbose, quite often you will see the link go up,
then down again, then up again.

Your solution would enable tx after the first link
up, which unfortunately would allow tx while the
link was down.

You probably would want to enable tx after the
last link up.

PS This binary up/down behaviour is not to be 
referred to as "bouncing"  :)

--
aboyd
Re: IO-PKT send a packet on startup.  
On 18/02/10 04:31 AM, Akash Goswami wrote:
> Hi Guys,
>
> I just cudnt stop myself jumping in :-)
>    
Thanks for jumping in :-)
> AFAIK, only completing autoneg wouldn't be sufficient in this case.
> settings needs to be adjusted according to PHY autonegotiation
> results,
Just so we're on the same page with terminology. I would include all 
that as part the definition of autoneg being "concluded". I.e. the link 
is operational - ready - everything has been set up for stack to start 
using it.

/P