Dan Williams wrote:
On Wed, 2005-01-26 at 19:31 +0100, Tom Parker wrote:This seemed like an interesting little project (especially after a few frustrations with my day work), and so I've actually just implemented it :-) Easier than I thought, patch against current CVS attached. What it's doing at the moment is if we fail all of the standard MII checks, then it waits 3 seconds for an ethernet frame, and reports 'link ok' if we get one. There's some setsockopt() work with SO_BINDTODEVICE that *should* only get frames sent to the relevant interface, but can someone double-check please.Tom, I haven't forgotten this patch :) I spent some time this weekend thinking about it, and how to generalize the patch for continuous operation. The patch you've got only checks for link on startup (because that's the only time that the mii code is used in NM). So how can we use this code to work around drivers that don't know link- detection on their own hardware? I had the though of using a GIOChannel linked to the fd of the data-read socket on the device. We'd integrate this GIOChannel into the device thread's main loop, and it would get triggered whenever there was data on the socket to be read. This way, we'd set the LINK = TRUE whenever incoming data was detected. Furthermore, we'd have to have a timeout of some sort that would set LINK = FALSE when data hadn't appeared for a while (not sure how long), possibly waking up every so often and checking the last time that data was received , which would be updated by the GIOChannel's callback. The only problem I could think of here was data throughput. If our GIOChannel callback is being triggered every time that incoming data was present, that would be fairly often if you're transferring a file or downloading something. I haven't tested that out, but I would assume that we would start using much more CPU than we do now. One way to deal with that would be to have the GIOChannel remove & re-add itself if its been called more than a certain number of times in 10s (ie, making it take a breather for a while). This gets rather complicated though as you have a number of idle/timeout functions and the GIOChannel callback all interacting with each other. Anyone got any better ideas? We can't just have a timeout (because it might miss data on the socket that came before it was called) and we can't just have the GIOChannel callback (because then we'd never get called to set LINK = FALSE when no data arrived after a certain time, and because it might get called TOO often), but having both seems a bit complicated. However, given the number of stupid drivers out there, we might have to eat the complexity and deal with it. Tom? Dan _______________________________________________ NetworkManager-list mailing list NetworkManager-list gnome org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Hello, I've been looking into the sk98lin driver today and did some mailing with syskonnect (the company that made the driver) and this driver doesn't support the MII stuff but is does print out a message into /var/log/messages when you plug in a cable and plug it out again. So it must be possible to detect this in some sort of way. Bart -- Bart Vanbrabant <bart vanbrabant zoeloelip be> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1
Attachment:
signature.asc
Description: OpenPGP digital signature