Re: pcap: forcing pcap_loop() failures

[Michael Tuexen <Michael.Tuexen () lurchi franken de>]

Why not use the 'any' device on Linux? I'm not sure if it will be  
supported in 2.6.20, but
in recent kernels it is :-)

Best regards
Michael

On Aug 16, 2006, at 8:15 PM, Richard H. wrote:

> Level:  pcaplib novice
> OS:  Linux 2.6.20
>
> I've been running a pcaplib app that reads continually from a  
> network switch port and processes a well-defined application  
> protocol.  Let's say the network interface it reads from is 'eth0'.
>
> I need to augment this app to handle the failover to a different  
> network switch port connected to a different network interface on  
> the host ('eth1'). There is no traffic on the failover switch  
> unless the primary switch fails. "Fails" means zero packet flow,  
> not merely the loss of packets containing the application  
> protocol.  Once the primary switch has been repaired, I need to  
> detect the loss of packet flow on the network interface attached to  
> the failover switch and start reading again from network interface  
> attached to the primary switch port.
>
> This all needs to happen automagically.
>
> The most straightforward way I can think of to do this is to create  
> two handles:
>
> pcap_t * primary_dev ;    // "eth0"
> pcap_t * failover_dev ;    // "eth1"
>
> ...and initialize them during program startup, before calling  
> pcap_loop():
>
> primary_dev = pcap_open_live( "eth0", BUFSIZ, 1, -1, errbuf ) ;
> failover_dev = pcap_open_live( "eth1", BUFSIZ, 1, -1, errbuf ) ;
>
> ...and then do some abomination like this, so that if the first  
> pcap_loop() fails the second is invoked:
>
> FOREVER()
> {
>   // condition normal.  Read from priimary capture interface
>    pcap_loop( primary_dev, -1, myCallback, NULL ) ;
>
>   // If we're here, the call above has failed.  Time to read from  
> the failover interface
>    pcap_loop( failover_dev, -1, myCallback, NULL ) ;
>
>    // If we're here, the failover interface has failed.  Hopefully  
> this means the primary
>    // is back up, because we're going back to the top of the loop
> }
>
> But this clearly isn't going to work as is.  For one, the mere loss  
> of traffic itself probably won't make pcap_loop() fail.  Two, even  
> if myCallback() keeps a count of the number of times it is  
> consecutively called without packet data, and uses this to infer a  
> switch failure, I still can't see any way from within myCallback()  
> to make pcap_loop() fail.
>
> Has anyone used pcaplib this way?  If so, which pcablib calls  
> should I look at to suss out the solution?
>
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.