On Mon, 2006-08-28 at 20:07 +0200, Daniel Hokka Zakrisson wrote:
> Eugene Roux wrote:
> > On Fri, 2006-08-25 at 01:30 +0200, Herbert Poetzl wrote:
> >>On Thu, Aug 24, 2006 at 09:15:09PM +0200, Eugéne Roux wrote:
> >>>On 24 Aug 2006, at 5:14 PM, Baltasar Cevc wrote:
> >>>>I'm not sure, but that may be a priviledge problem - try if it works
> >>>>when adding the appropirate capabilities if you haven't done so yet
> >>>>(I think it should be CAP_NET_ADMIN). However adding that capability
> >>>>is a security issue as the guest is allowed to change too many
> >>>>network settings then.
> >>>
> >>>I assumes so initially as well, but since I got little out of the
> >>>system, I decided to throw CAPS at it in the hope that I could tighten
> >>>up to the express limit it required once I got it working.
> >
> > <snip />
> >
> >>>Accessing these modems using "cu -l /dev/modem" works fine, but when I
> >>>try and bring up a PPP link I get the following:
> >>
> >>> root@vs01-vc01:/# /usr/sbin/pppd.org user root call FOOCHAT
> >>> chat: Aug 22 12:07:35 CONNECT 1800000
> >>> Serial connection established.
> >>> Using interface ppp0
> >>> Connect: ppp0 <--> /dev/modem
> >>> Could not determine remote IP address: defaulting to 10.64.64.64
> >>> ioctl(SIOCSIFDSTADDR): Cannot assign requested address(99)
> >>> Connection terminated.
> >>> Connect time 0.1 minutes.
> >>> Sent 126 bytes, received 150 bytes.
> >>> root@vs01-vc01:/#
> >>
> >>could you run that through strace -fF please and
> >>narrow the syscalls down to the relevant ones
> >>around the ioctl(SIOCSIFDSTADDR)?
> >
> >
> > 3840 fcntl64(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=1020, len=1}) = 0
> > 3840 fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=1020, len=1}) = 0
> > 3840 fcntl64(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=1028, len=1}) = 0
> > 3840 fcntl64(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=1020, len=1}) = 0
> > 3840 fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=1020, len=1}) = 0
> > 3840 fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=1028, len=1}) = 0
> > 3840 ioctl(4, JFFS_PRINT_HASH or PPPIOCGFLAGS, 0xbfd30dd4) = 0
> > 3840 ioctl(4, PPPIOCSFLAGS, 0xbfd30dd4) = 0
> > 3840 ioctl(5, SIOCGIFCONF, {32, {{"eth0:vc01", {AF_INET, inet_addr("10.121.23.187")}}}}) = 0
> > 3840 ioctl(5, SIOCGIFFLAGS, {ifr_name="eth0:vc01", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
> > 3840 ioctl(5, SIOCGIFNETMASK, {ifr_name="eth0:vc01", ifr_netmask={AF_INET, inet_addr("255.255.255.255")}}) = 0
> > 3840 ioctl(5, SIOCSIFADDR, 0xbfd30dac) = 0
> > 3840 ioctl(5, SIOCSIFDSTADDR, 0xbfd30dac) = -1 EADDRNOTAVAIL (Cannot assign requested address)
>
> Does your guest have the hide_netif flag set? Try
> echo "~hide_netif" >> /etc/vservers/<name>/flags
> and restart the guest, or alternatively, run
> vattribute --xid <name> --set --flag ~hide_netif
> for testing.
Relief!
That seems to have done the trick: we currently have two PPP links
going, one on each of the Virtual Servers. The links seem to establish
and then seems to run stably.
We'll monitor it for 24 hours, dropping and re-establishing the links
and then go for broke: bring up a third Virtual Server and another PPP
link.
Thanks for everyone helping so far, it is truly appreciated.
Here's holding thumbs...
Eugéne
-- Eugéne Roux "Fairy tales do not tell children the dragons Cynical Romantic, exist. Children already know dragons Romantic Philosopher, exist. Fairy tales tell children the Philosophising Cynic dragons can be killed." G.K. Chesterton
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver