Re: [9fans] bug or feature ? --- ip/ping -6
your ipv4 "embedding" doesn't need to be part of the ping tool. it's not commonly used anyway. allowing the ping tool to do dns lookups on the other hand are a common convenience.
Re: [9fans] bug or feature ? --- ip/ping -6
unfortunately, the simlification removes the code that solves an important
use case. it's important to be able to specify the protocol or network stack,
such as in
ip/ping /net.alt/icmp!someaddress
the diff is here and i'll be working on a patch.
the basic idea is to translate only the dns names to ip addresses, and then
reassemble the string. this way we can keep any decorations such as
/net.alt/icmpv6!...
- erik
---
lilly; diff -c `{yesterday -n20 /sys/src/cmd/ip/ping.c} /sys/src/cmd/ip/ping.c
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:28,34 - /sys/src/cmd/ip/ping.c:28,34
typedef struct {
int version;
- char*net;
+ char*protoname;
int echocmd;
int echoreply;
unsigned iphdrsz;
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:393,398 - /sys/src/cmd/ip/ping.c:393,401
/* from /sys/src/libc/9sys/dial.c */
+ static char defnet[] = "/net";
+ static char defproto[] = "icmp";
+
enum
{
Maxstring = 128,
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:406,416 - /sys/src/cmd/ip/ping.c:409,414
char*netdir;
char*proto;
char*rem;
-
- /* other args */
- char*local;
- char*dir;
- int *cfdp;
};
/*
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:417,423 - /sys/src/cmd/ip/ping.c:415,421
* parse a dial string
*/
static void
- _dial_string_parse(char *str, DS *ds)
+ dsparse(char *str, char *defproto, DS *ds)
{
char *p, *p2;
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:425,437 - /sys/src/cmd/ip/ping.c:423,435
ds->buf[Maxstring-1] = 0;
p = strchr(ds->buf, '!');
- if(p == 0) {
- ds->netdir = 0;
- ds->proto = "net";
+ if(p == nil) {
+ ds->netdir = nil;
+ ds->proto = defproto;
ds->rem = ds->buf;
} else {
if(*ds->buf != '/' && *ds->buf != '#'){
- ds->netdir = 0;
+ ds->netdir = nil;
ds->proto = ds->buf;
} else {
for(p2 = p; *p2 != '/'; p2--)
/n/dump/2015/1214/sys/src/cmd/ip/ping.c:443,506 - /sys/src/cmd/ip/ping.c:441,560
*p = 0;
ds->rem = p + 1;
}
+ if(ds->netdir == nil || ds->netdir[0] == 0)
+ ds->netdir = defnet;
}
/* end excerpt from /sys/src/libc/9sys/dial.c */
- /* side effect: sets network & target */
- static int
- isv4name(char *name)
+ char*
+ dstopretty(DS *ds, char *name)
{
- int r = 1;
- char *root, *ip, *pr;
+ char *port;
+
+ port = strchr(ds->rem, '!');
+ if(port == nil)
+ port = "";
+
+ if(ds->netdir == defnet)
+ return smprint("%s!%s%s", ds->proto, name, port);
+ else
+ return smprint("%s/%s!%s%s", ds->netdir, ds->proto, name, port);
+ }
+
+ char*
+ nametoip(char *name0, int *ipver, char **target, char **pretty)
+ {
+ int n,fd;
+ char buf[128], ip6[128], ip4[128], *cs, *s, *p, *name, *addr, *ip;
DS ds;
- _dial_string_parse(name, );
+ *target = nil;
+ dsparse(name0, defproto, );
- /* cope with leading /net.alt/icmp! and the like */
- root = nil;
- if (ds.netdir != nil) {
- pr = strrchr(ds.netdir, '/');
- if (pr == nil)
- pr = ds.netdir;
- else {
- *pr++ = '\0';
- root = ds.netdir;
- network = strdup(root);
+ /* do not override protocol specified */
+ if(*ipver == -1 && ds.proto != defproto){
+ if(strcmp(ds.proto, v4pr.protoname) == 0)
+ *ipver = 4;
+ else if (strcmp(ds.proto, v6pr.protoname) == 0)
+ *ipver = 6;
+ }
+
+ name = ds.rem;
+ ip6[0] = 0;
+ ip4[0] = 0;
+ if(isdottedquad(name)){
+ snprint(ip4, sizeof ip4, "%s", name);
+ goto match;
+ }
+ if(isv6lit(name)){
+ snprint(ip6, sizeof ip6, "%s", name);
+ goto match;
+ }
+
+
+ cs = smprint("%s/cs", ds.netdir);
+ fd = open(cs, ORDWR);
+ if(fd < 0)
+ sysfatal("cannot open %s: %r", cs);
+ free(cs);
+
+ addr = smprint("tcp!%s!1", name);
+ if(write(fd, addr, strlen(addr)) != strlen(addr)){
+ close(fd);
+ sysfatal("cannot write %s to %s: %r", addr, cs);
+ }
+ free(addr);
+ seek(fd, 0, 0);
+ while((n = read(fd, buf, sizeof(buf)-1)) > 0){
+ buf[n] = 0;
+ ip = strchr(buf,' ');
+ ip++;
+ p = strchr(ip,'!');
+ *p = 0;
+ if(isdottedquad(ip)){
+ if(ip4[0] == 0)
+ snprint(ip4, sizeof ip4, "%s", ip);
+
Re: [9fans] bug or feature ? --- ip/ping -6
> i spent some time thinking about this problem. > > the purpose of -6 is to force icmpv6. (one can use a v4 address > with icmpv6, that works due to ipv4 embedding.) this is not the same as > controlling name lookup. since there are better more flexible tools > for doing that by hand. the result can be fead to ip/ping. > > it's kind of an ugly problem. and it turns out that the patch as given breaks things like ip/ping /net.alt/icmpv6!hostname - erik
Re: [9fans] bug or feature ? --- ip/ping -6
On Sun Jan 3 13:42:21 PST 2016, 23h...@gmail.com wrote: > your ipv4 "embedding" doesn't need to be part of the ping tool. it's > not commonly used anyway. i think the attribution here is false. i read the man page for that information. in any event, ping as patched is wrong. addresses like icmpv6!address must be accepted. this may make the -4 flag silly in it's current form. > allowing the ping tool to do dns lookups on the other hand are a > common convenience. but as such, one loses precision. for example if i use a name, i can't easily force the name lookup to find the ip i'm thinking of. > perhaps i misunderstand. i'm not against adding zeros at the front. see /sys/src/libip/ipaux.c^/uchar v4prefix - erik
Re: [9fans] Install: root file system
On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote: > i'm not sure what the root cause of your problem is, I'm now suspecting that the underlying problem is that a 9fat is a dos, but that is a special dos: part of a plan9 slice, so whether kfs or fossil supplementary partitions are expected. I have changed the MBR identifier to big FAT16 (6) and in this case 9load doesn't find a Plan9 slice and ask for a kernel, the sdE2!dos!9pcdisk.gz is OK (but it panics after since it doesn't ask for a plan9.ini). > due to not enough data, > but it does remind me of a limitation that has been bugging me. > > to boot from usb cleanly, i added a bit to the boot process that creates a > loopback > sd device /dev/sdu0 that points to the usb disk device. i've been booting my > auth > server this way for some time. > The idea is interesting. Another idea/question appeared to me: could it be possible to add a device identifier # to the booting device or publish it in the name space under /boot? Corollary: when an embedded bzfilesystem ships with the kernel, is there an device identifier that allows to access it? (From a cursory look at the proto, it seems that the file is published under /boot, but since the 9pcflop has no the sdiahci drivers, I try to simply catenate the 9pccd---or 9pcdisk FWIW---with the root.bz2 extracted, guessing that this is 9load task to arrange the loading, but I didn't find a way to access it directly from kernel hierarchy, since it is not visible in namespace). > it seems to me that i really screwed this up. what i really want is a sd > device > that always points to the boot drive, the one bios refers to as 0x80. > givem this, one can then put something like "bootargs=local!#S/sdB0/fs" > in plan9.ini. this will allow the 9atom usb install image to run off any > bootable > media (for which we have drivers). > :-) This has always been the "pleasure" of the bootstrapping procedure in the PC world. If I understand correctly, it is normal on other architectures to pass through the bios to access some hardware. With the PC, there is the limitation of the interface and, essentially, the real mode problem. But it is indeed a bit frustating to see devices accessed at booting (hurrah! my hardware is recognized!) and suddenly not recognized (when the BIOS is not used anymore and the kernel is on is own without the drivers)... Related question (for whoever has an answer): unfortunately my node has only a PS2 combo, so that I could, theoretically, have whether a PS2 mouse xor a PS2 keyboard. In fact, when the mouse and keyboard are both connected via USB, 9pcflop has no problem: I have keyboard and mouse (BIOS emulating PS2 interfaces). If I use 9pccd or 9pcdisk, I loose the keyboard (and don't have the mouse if it is connected to USB). So it seems I could have a running Plan9 (it works for mouse and keyboard attached via usb with 9pcflop, but 9pcflop doesn't recognize the SATA/AHCI disks; 9pccd or 9pcdisk recognize the sdiahci, but don't recognize the usb mouse and keyboard; I hope a synthesis is possible with the "best" of all worlds)? But what does the usb attachment work with 9pcflop for mouse and keyboard and doesn't work for the others---perhaps because 9pcflop doesn't recognize usb and hence fall back to a PS2 BIOS provided interface? > so, i'm preparing a patch that will present the boot device as /dev/sdB0 > regardless > of what underlying disk driver or protocol is being used. here's the output > from > my test machine. it's been booted over the network, but even so bios has > assigned > a 0x80 drive, and it's been found and configured: > > >>sdB loop #S/sdF0/data > sdE ahci ahci port 0xfe00fb538000 pci 0.17.4: 64a ncq alp led clo > pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 4 ghc 8002 > isr 0 pi f 0-3 ver 10300 > sdF ahci ahci port 0xfe00fb532000 pci 0.31.2: 64a ncq alp led clo > pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 6 ghc 8002 > isr 0 pi 3f 0-5 ver 10300 > sdN nvme port 0xfe00fb41 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 > stride 1 to 2 fatal 0 > sdO nvme port 0xfe00fb30 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 > stride 1 to 3 fatal 0 > That's interesting! For the mean time, I guess I will have to put an unix to serve 9P for a locally loaded kernel---but I will have to adapt the inst/ scripts since some programs are in the image embedded for the installation but are not present on the CDROM. And I will have to find a way to be able to use both mouse and keyboard, or it will be a no-go. -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] bug or feature ? --- ip/ping -6
-4 and -6 should error when used with an ip of the wrong type. when used with domains correct behavior should be trivial and if there's no dns response for A or it should error once again.
