Lasse Skov(deleted)
|
IO-PKT send a packet on startup.
|
Lasse Skov(deleted)
02/15/2010 6:15 AM
post47301
|
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.
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/16/2010 8:57 AM
post47364
|
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
|
|
|
Andrew Boyd(deleted)
|
RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/16/2010 9:43 AM
post47379
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/16/2010 10:24 AM
post47393
|
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
|
|
|
Lasse Skov(deleted)
|
Re: IO-PKT send a packet on startup.
|
Lasse Skov(deleted)
02/16/2010 10:46 AM
post47402
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/16/2010 10:49 AM
post47404
|
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
|
|
|
Lasse Skov(deleted)
|
Re: IO-PKT send a packet on startup.
|
Lasse Skov(deleted)
02/16/2010 11:42 AM
post47419
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/16/2010 12:03 PM
post47423
|
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
|
|
|
Lasse Skov(deleted)
|
Re: RE: IO-PKT send a packet on startup.
|
Lasse Skov(deleted)
02/16/2010 10:42 AM
post47400
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/16/2010 10:46 AM
post47401
|
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
|
|
|
Andrew Boyd(deleted)
|
RE: RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/16/2010 10:46 AM
post47403
|
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
|
|
|
Lichun Zhu
|
Re: RE: RE: IO-PKT send a packet on startup.
|
Lichun Zhu
02/16/2010 1:24 PM
post47438
|
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?
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/16/2010 1:34 PM
post47441
|
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
|
|
|
Lichun Zhu
|
Re: RE: RE: RE: IO-PKT send a packet on startup.
|
Lichun Zhu
02/16/2010 3:44 PM
post47452
|
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?
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/16/2010 3:56 PM
post47456
|
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
|
|
|
Sean Boudreau(deleted)
|
Re: RE: RE: RE: IO-PKT send a packet on startup.
|
Sean Boudreau(deleted)
02/16/2010 4:00 PM
post47458
|
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
>
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/16/2010 4:08 PM
post47460
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/17/2010 12:59 PM
post47548
|
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
|
|
|
Andrew Boyd(deleted)
|
RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/17/2010 1:20 PM
post47560
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/17/2010 2:28 PM
post47581
|
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
|
|
|
Andrew Boyd(deleted)
|
RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/17/2010 2:37 PM
post47582
|
RE: IO-PKT send a packet on startup.
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/17/2010 3:00 PM
post47583
|
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
|
|
|
Akash Goswami(deleted)
|
RE: IO-PKT send a packet on startup.
|
Akash Goswami(deleted)
02/18/2010 4:31 AM
post47626
|
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
|
|
|
Andrew Boyd(deleted)
|
RE: IO-PKT send a packet on startup.
|
Andrew Boyd(deleted)
02/18/2010 9:10 AM
post47652
|
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
|
|
|
Patrik Lahti
|
Re: IO-PKT send a packet on startup.
|
Patrik Lahti
02/18/2010 10:30 AM
post47668
|
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
|
|
|
|